Если сменить IP и "толкнуть" очередь, ремблер вбирает письма с того же домена и снова до достижения лимита. Значит привязывается к IP.
Все, что я описываю действительно имеет место, но рассылка длится допустим часов 5-10 и никто никуда не спешит. Проблема в том, что MTA проектируются для нормальных условий, а не для спамеров. Они останавливают очередь доставки к хосту если залипло хоть одно письмо. И не используют сразу несколько IP для отправки.
В принципе в postfix есть интерфейсы к SQL, а там может даже можно изобразить динамический выбор IP с помощью transport_maps, но это ж надо копать и экспериментировать. У спамеров скорее всего свои программы.
но ведь для этого нужно ПРОГРАММИРОВАТЬ.
Будь ТС в состоянии это делать вопрос бы вообще не стоял.
Ну так и сделай для каталога /tmp файловую систему tmpfs.
По крайней мере это точно поможет, при условии что верно оценен характер нагрузки.
>key_buffer = 16M
почти наверняка это маловато.
Плохо, особенно рамблер. Почту он принимает в конце концов, но greylisting там мешается сильно. Не известно можно ли с ними договориться о снятии лимита или же лимит сам снимается при достаточно большом потоке. Поэтому вам придется что-то придумывать с пулом IP и так настроить MTA, чтобы при получении временной ошибки на этот домен не останавливалась вся очередь на этот конкретный домен.
Хорошо, разрешаю вам игнорировать такую статистику и собрать свою.
Учитывая, что другой статистики по mysql нет, а личная статистика вряд ли будет больше, любые ваши рассуждения будут еще более безосновательны.
На мой взгляд, 24 случая отобранных и классифицированных из сомнительных случаев - это мало для выбора президента, а для выявления закономерностей вполне достаточно.
Lupus, так я и говорю, что увлекшись качественными вопросами, не видят ошибок количественных. И ничего оно им не дает особенного - и файловую систему выбирают одну и ту же, и опции монтирования одинаковые. Ничего ими не движет, кроме "а пусть у меня будет диск С:, D: и E:".
Во всех случаях за устранение проблем бизнес заплатил по довольно приличным тарифам. Так что это серьезная проблема с точки зрения этих людей.
Lupus, как следует из отчета, статистически значительное число администраторов делает это не так, допуская ошибки при выборе размеров разделов файловых систем приводящие к серьезным проблемам.
michaek, ну так я же специально ссылку давал - читай, аргументируй.
вот тут статистика занятная опубликована http://www.percona.com/redir/files/white-papers/causes-of-downtime-in-mysql.pdf
Table 2 is a breakdown of storage faiure incidents.
Item Incidents % of Total Disk Full 9 37.5% SAN 5 20.8% RAID Controller 4 16.7% Other Storage 3 12.5% Filesystem 2 8.3% Permissions 1 4.2%
То есть, ошибки в разбиении - самая частая проблема приводящая к неработоспособности сервера mysql из числа всех проблем с хранением файлов.
Что бы тут не говорил myhand, а распланировать нормально то никто не умеет.
Бейте на один раздел, господа начинающие обменистраторы.
Постройте графики apache volume bytes, apache requests и apache processes.
Даже если нет настоящего распределенного ddos, на их основе можно заметить необычную активность на сайте как то чужой парсер или массовую переиндексацию от ПС, что тоже может являеться причиной роста нагрузки.
