Думаю, да. По моим наблюдениям, фря порой богаче линукса.
Dimanych, это я просто пример привёл. Не думая, что именно он сделает.:)
Вообще, это такое же правило, как и обычно.
Определяете условие для отслеживания нарушителей и вместо "-j DROP" пишете "-j LOG 'error' ".
Или вставляете LOG после всех правил об ACCEPT-ах, так определите кто и куда к вам ломится.
И лучше использовать limit в таких правилах, чтобы не зафлудился журнал :)
connlimit можно компенсировать recent - ом.
Причём более гибко. Как правило, применяется для отбрасывания брутфорсеров на SSH.
Можно гибче :) К Вашим правилам добавить:
iptables -A FORWARD -p tcp --syn -m limit --limit 5/s -j LOG " - flooder!"
в настройках syslog-ng сделать отправку в пайп и банить сразу.
Хотя можно использовать тот же recent для этого.
Merchant Webmoney - http://webmoney.ru/rus/merchants/index.shtml - читали?
hpulse.ru - может проверить как резолвинг домена, так и доступность сервера/сайта, текста ответа и много чего ещё. Проверяет из одной точки.
host-tracker.ru тоже работает нормально. DNS вроде не проверяет, но работает с разных точек. Иногда показывает проблемы о доступе из разных точек.
ИМХО, первым лучше пользоваться для проверки работоспособности серверов/сервисов/сайтов, вторым - для проверки доступности сайта/сервера.
Сам пользуюсь обоими, доволен обоими (первый - мой, второй - для проверки самого себя).
Аптайм считают оба.
+1 за DD,
только подождите пару минут перед второй операцией (или сделайте 'sync'), так как данные на момент чтения частично могут быть в дисковом кеше, а не на диске (по крайней мере в линуксе точно).
Ещё маленькая поправка:
dd if=/dev/zero of=file.bin bs=8192 count=100000 - по-моему, будет реальнее, если программа пишет 8-кбайтовыми блоками на диск.
Ну, если так, то 2xSCSI в raid-1, NxSATA в raid-5.
Вообще, надо исходить из требуемой скорости чтения-записи, объёмов данных (какими кусками читать-писать будете) и требуемого объёма массива.
Как уже говорил, обычный 'dd' на линуксе выдаёт 40/50 Мб/с чтение-запись на одном диске, 300/450 Мб/с на 15-ти дисковой raid-5.
Это для объёмов читаемых/записываемых данных 100-200Gb.
Для разовой записи/чтения 250Мб raid-5 выдаёт 0.6/>1 Гб/с, так как использует свой кеш.
Имейте в виду, что raid-5 теряет в надёжности с каждым новым диском. Чем больше в нём дисков - тем она меньше. А скорость больше :)
Посмотрите в сторону 3ware - http://www.3ware.com/support/OS-support.asp
Как говорят, есть поддержка FreeBSD.
Использую под линуксом 7000 и 9000 серии, проблем не знал. Модули встроены в ядро. Возможно, и во фре так.
Есть утилита для ребилдинга массива "налету" - tw_cli. Вообще, много чего могут.
На raid-5 (9650SE-16ML) с 15-ю дисками у меня получилась скорость записи под 300Мб/сек.
А мне нет... 83 бакса так и зависли.
Всё обещали выплатить, разобраться в причинах задержки и тп, а воз и ныне там.
Видать, избирательно работают.:)
Уже не пишу им, бог с ними.
У меня та же ситуация будет когда-нибудь, только XEON 2.8.
Расчёт времени, по максимуму, такой (ДЦ СТЕК):
- отключение сервера (кнопкой "повер", через ACPI демон): 1.5 мин.
- отключение питания, вынимание из стойки (шасси, находится внизу) и перенос в комнатку: 5 мин.
- открытие корпуса, доставание кривыми руками нового проца, сборка его: 3 мин.
- установка проца: 5 мин.
- закрытие корпуса и перенос в аппаратную: 3 мин.
- установка в стойку, подключение кабелей: 5 мин.
- загрузка ОС: 2 мин.
Получаем: 24.5 минут --> 30 минут максимум.
По ядру никаких проблем не будет, так как XEON уже видится ядром как два процессора (то есть ядро SMP). Худшее, что может случиться - это ядро не увидит его, но ОС будет работать.
Проверьте количество процессоров в настройках ядра, их должно быть 4. Я с самого начала так его собирал, но у Вас может быть по-другому.
PS. Свой сервер собирал сам, но новый проц не устанавливал и описываемых работ не производил.
PPS. Знаю, что спецов тут много, не сочтите за окончательный вариант (помидоры могу достать и из холодильника :)).
Достаточно перезапустить mysql.
mytop поможет увидеть запросы в реальном времени.
Проблема мб в pconnect-ах или большом притоке пользователей.
Уберите pconnect-ы и посмотрите что изменится.
Бывает, что из-за их использования число соединений растёт. А каждое, даже спящее, соединение требует для себя выделения буферов. При sleeping соединениях скорее всего была съедена вся память и mysql ушла в своп. Из него она может и не вернуться без перезапуска (так как запросы продолжают поступать).
Как вариант, можно уменьшить количество соединений на пользователя или на всю базу вцелом. Но если проблема в pconnect-ах, то от этого она только рашьше отрубится.
Ещё вариант - написать скриптик, который будет анализировать show process list и убивать долго спящие процессы. Так сделал один мой знакомый, у него работает. Хотя можно и через my.cnf это решить.
