так зачем вы этот код ошибки выводите пользователю ?
выполняете alter table, проверяете код ошибки и игнорируете ошибку в случае если этот код соответствует ситуации с уже созданным полем. любые другие ошибки - проблема, требующая реакции пользователя.
недостаточно решительно действуете. Будьте последовательны и сделайте так чтобы машины с IPv4 ваш сайт не смогли открыть. Вот это бы было сильное заявление. Слабо?
Судя по размышлениям ТС, в его случае - ошибка.
Но другие люди могут делать подобную настройку вполне осознанно. ssh обычно рвет соединение при N неправильных попытках входа. Не провисит такое соединение долго.
И вполне оправдано. Все равно эти люди не сознательно трафик экономят, а занимаются "повышением секурности" хостинга с помощью такой фигни как блокирование ssh.
строго говоря, tcpdump не гарантирует захвата всех пакетов прошедших по интерфейсу.
Если всякие параметры ядра типа net.ipv4.tcp_* хорошенько задрать вверх, то соединения могут провисеть довольно долго.
Ну и баг, разумеется, не нужно исключать - это же centos5, где все давно протухло.
Просто такой ответ самый универсальный и не зависит от технологий используемых на сайте. Конечно, лучше смотреть непосредственно на веб-сервер, ведь атака направлена на самые ресурсопотребляющие части сайта. То есть, например, посмотреть /server-status или логи access.log.
Ботнету выгодно реализовать полный dns-стек чтобы оперативно узнавать куда перетащили сайт, так что обычно не кешируют ничего.
так вы и не используйте только этот метод определения. используйте по порядку все, что придет в голову.
Pinkie, видимо, xfs с журналом на ramdrive, но лучше тестировать самостоятельно в ваших конкретных условиях. тем более, что серверов у вас несколько и наверное есть возможность тестировать постепенно и сравнивать.
Еще есть сценарии, когда один из дисков в raid1 попеременно убирают из массива, делают оптимизацию (стирение через trim) и снова включают. В этом случае вероятность поломки не такая уж большая, но появляется возможность использовать любую другую файловую систему типа reiserfs или ext2.
Некоторые протоколы чувствительны к отправке целых пакетов и их разбиению. RDP в их числе.
Попробуйте уменьшить MTU и на сервере-шлюзе и на сервере с RDP.
Кстати, зачем у вас RDP связан с SMTP? странная картинка.
А это планируются или имеются? 500 тыс уникальных посетителей, которые не просто попадают по ошибке, а что-то делают на сайте ? На одном единственном сервере? Это должен быть весьма специфичный проект. Отсюда и некоторые посты не касающиеся вопроса непосредственно.
Что касается конкретно специфики использования SSD, можно использовать файловую систему поддерживающую trim : Ext4, XFS, Btrfs, и, как ни странно, FAT. Практически стоит пробовать только EXT4 и XFS.
Для отключения журнала в EXT4 опция называется has_journal, в man tune2fs все написано.
Насчет XFS что-то не вижу ничего, но есть возможность использовать для журнала другое устройство и это устройство может быть диском в памяти. Эффект должен быть почти такой же как и от отключения журнала.
Замечания про /etc/fstab практически не отличаются в linux. Есть и tmpfs и noatime и nodiratime.
tmatm, а вы купите Сервер вместо компьютера. На ssd или raid c памятью и батарейкой должно быть нормально. Можно, например, на маленький ssd писать этот binlog.
Судя по ошибкам, насчет binlog угадал я правильно.
