Пропустить исходящую почту eximʻa через скрипт перед отправкой?
Я запускаю сервер cPanel. Этот сервер недавно был взломан, и рассылался спам, поэтому я хотел бы отслеживать каждое электронное письмо, которое отправляет Exim.
Можно ли заставить Exim запускать скрипт перед помещением электронного письма в очередь?
I хотите, чтобы Exim отправлял сообщение «От: t изменить что-либо в странности этого шаблона, но это означает, что он практически менее разрушителен.
Почему время отклика обратно пропорционально частоте запросов?
Разве сервер не должен реагировать быстрее, когда он менее занят обработкой запросов. ?
Есть ли какие-либо предложения, как заставить Apache «использовать» меньшую нагрузку?
Этот шаблон периодический. Это означает, что он появится, если количество показов упадет ниже 200 запросов в минуту, что происходит (из-за естественной активности пользователя) с поздней ночи до раннего утра.
Запросы представляют собой очень простые POST-запросы, отправляющие JSON длиной менее 1000 символов. - этот JSON сохраняется (добавляется в текстовый файл) - вот и все. Ответ - просто «-».
Данные, показанные на графиках, были записаны самим Apache:
LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance
Это обычное поведение в центрах обработки данных. Время, когда у вас медленное время отклика, соответствует тому, что обычно называется пакетным окном. Это период времени, когда ожидается, что активность пользователя будет низкой, и можно будет запускать пакетные процессы. Резервные копии также делаются в этот период.Эти действия могут перегрузить ресурсы сервера и сетей, вызывая проблемы с производительностью, как вы видите.
Есть несколько ресурсов, которые могут вызвать проблемы:
- Высокая загрузка ЦП. Это может привести к тому, что apache будет ждать отрезка времени для обработки запроса.
- Большое использование памяти. Это может очистить буферы, которые позволяют apache обслуживать ресурсы, не читая их с диска. Это также может вызывать пейджинг / замену рабочих apache.
- Высокая дисковая активность. Это может привести к тому, что операции ввода-вывода диска будут помещены в очередь с соответствующими задержками в обслуживании контента.
- Высокая сетевая активность. Это может привести к постановке пакетов в очередь для передачи, увеличению числа повторных попыток и иным причинам к ухудшению обслуживания.
Я использую sar , чтобы исследовать подобные проблемы. atsar может использоваться для сбора sar данных в файлы ежедневных данных. Их можно изучить, чтобы увидеть, на что похоже поведение системы в дневное время, когда производительность нормальная, и в ночное время, когда производительность переменная.
Если вы отслеживаете систему с помощью munin или какой-либо другой системы, которая собирает и составляет график использования ресурсов, вы можете найти там некоторые индикаторы. Я все еще считаю sar более точным.
Существуют такие инструменты, как nice и ionice , которые можно применять к пакетным процессам, чтобы минимизировать их влияние. Они эффективны только для проблем с процессором или вводом-выводом. Они вряд ли решат проблемы с памятью или сетевой активностью.
Перенос операций резервного копирования в отдельную сеть и уменьшение числа конфликтов в сети. Некоторое программное обеспечение резервного копирования можно настроить для ограничения используемой полосы пропускания. Это могло разрешить конфликты в сети.
В зависимости от того, как запускаются пакетные процессы, вы можете ограничить количество пакетных процессов, выполняемых параллельно. Это может фактически улучшить производительность пакетных процессов, поскольку они, вероятно, испытывают ту же конкуренцию за ресурсы.
То, что вы видите, мне кажется, что это может быть статистическая проблема. Возможно, это не так, ответ @BillThor вполне может быть правильным, но я опубликую это для полноты.
Графики времени ответа основаны на процентилях. Пул сэмплов из 800-1000 запросов - хорошее количество сэмплов для этого, пул из 50-100 запросов может быть не так уж и много.
Если вы предположите, что количество медленных запросов не является линейной функцией объема запроса, так что увеличение количества запросов на порядок не приводит к увеличению количества медленных запросов на порядок, тогда более высокие объемы запросов приведут к более низкому среднему времени запроса.
Есть ложь, большая ложь и статистика.
Моя гипотеза: у вас их три различные категории запросов:
- Обычный переменный поток, который содержит большинство запросов, и все они выполняются в течение 200-300 мкс.
- Небольшой поток с постоянной скоростью около 20 запросов в минуту (даже ночью). На выполнение каждого требуется около 2,500 мкс.
- Небольшой поток с постоянной скоростью около 10 запросов в минуту (даже ночью). Каждый из них занимает более 4000 мкс.
Ночью 50 запросов в минуту составляют соответственно 20 + 20 + 10. Итак, результат 50% процентиля теперь сильно зависит от результата потока 2. А 95% процентиля зависит от потока 3, поэтому он никогда не может даже отображаться на графике.
В течение дня потоки 2 + 3 хорошо скрыты выше 95% процентиля.
Чем больше я смотрю на это, тем больше склоняюсь к мысли, что есть проблема со сбором данных.
Во-первых, с вашим TPS происходит что-то действительно странное. . Хотя в целом картина выглядит нормально, есть очень резкий разрыв, который происходит примерно в 21:00, а затем снова примерно в 7:00. Обычный график будет намного более плавным во время перехода в непиковые часы.
Это говорит о том, что есть изменение в профиле, и у вас, возможно, есть 2 разных типа клиентов:
- Тот, который работает только с 7 утра ( ish) и 9pm (ish), на большой громкости, и
- другой, который, вероятно, работает круглосуточно, на более низкой громкости.
Вторая подсказка - около 18:00. Большую часть времени до и после мы имеем профиль громкости высокий - высокий TPS и низкая задержка. Но примерно в 18:00 происходит резкое падение с 800-1000 об / мин до менее 400 об / мин. Что могло быть причиной этого?
Третий намек - это уменьшение времени отклика 5-го процентиля. На самом деле я предпочитаю смотреть на минимальное время отклика (но 5-й процентиль, возможно, лучше) по двум причинам: он говорит мне время обслуживания (т.е. время отклика за вычетом очередей), а время отклика обычно соответствует Вейбуллу. Это означает, что режим (или наиболее распространенное значение) чуть выше минимума.
Таким образом, понижение в 5-м процентиле говорит мне, что в ряду внезапно произошел разрыв, и время обслуживания фактически упало, хотя и дисперсия, и среднее время отклика значительно увеличились.
Следующие шаги
На этом этапе я бы глубоко погрузился в журналы, чтобы выяснить, чем отличаются образцы малого объема 18:00 от образцов большого объема до и после него.
Я бы искал:
- различия в географическом расположении (в случае, если задержка влияет на $ request_time)
- различия в URL (не должно быть)
- различия в методе HTTP (POST / GET) (не должно быть)
- повторяющиеся запросы с одного и того же IP-адреса
- и любые другие различия ...
Кстати, «событие» в 18:00 является для меня достаточным доказательством того, что оно не имеет ничего общего с перегрузкой / активностью центра обработки данных. Чтобы это было правдой, перегрузка должна вызвать падение TPS, которое возможно в 18:00, но крайне маловероятно, чтобы вызвать устойчивое и плавно изгибающееся падение TPS в течение 10 часов с 21:00 до 7:00.
Хотя ответ @BillThor может быть правильным, маловероятно, что период низкой нагрузки полностью занят процессами резервного копирования (т.е. периоды точно совпадают).
Альтернативное объяснение - просто кеширование. Если данный сценарий / база данных / что-то еще не использовалось в последнее время, соответствующие кэшированные данные могли быть отброшены, чтобы освободить память для остальной части операционной системы. Это могут быть индексы в базе данных, буферы O / S по отношению к файлу или что-то подобное. Затем запрос должен будет восстановить эту информацию, если с момента последнего запроса прошло некоторое время. В периоды занятости этого не произойдет, поскольку последний запрос будет частым. Это также объясняет, почему вы наблюдаете низкое время ответа и высокое время ответа в период занятости.
Эта связь может иметь место в другом direction, если отправители запроса ждут завершения предыдущего запроса перед отправкой нового. В этом случае трафик падает по мере увеличения времени запросов (по любой причине) из-за очередей на стороне клиента.
Или это может быть артефактом ваших измерений - если на графике выше показано выполненных запросов , поскольку в отличие от поступающих запросов , скорость будет падать по мере увеличения времени обработки запроса (при условии конечной емкости: D).