Что веб-сервер Sun или конфигурация Сервера приложений могут вызвать “Из-за нерегулярной ошибки, запрос не мог быть обслужен”

Нет действительно многих tunables в курьере - можно настроить базовую машину, не само программное обеспечение.

Однако существуют некоторые вещи, которые можно сделать для улучшения производительности:

  1. Больше RAM. Я знаю, что Вы планируете сделать это, и я знаю, что это не то, что Вы хотите услышать, но это - единственный лучший выбор при улучшении производительности - оба, позволяя курьеру сохранить больше соединений открытым (IMAP берет 512K до 2M на связанный клиент), и путем разрешения большего кэша файловой системы. Пойдите 64-разрядные, если возможный и бросают 8 или 16 ГБ в почтовый сервер. RAM является дешевой. Время не.

  2. Удостоверьтесь, что Вы смонтировали файловую систему, размещающую Ваш maildirs с noatime опция. Это, предположительно, вмешивается в mutt почтовый клиент, но по моему опыту никогда не вызывал проблемы. Если Вы действительно должны и выполнять более новое ядро, можно использовать relatime - но noatime улучшает производительность много.

  3. Выберите хорошую файловую систему. ext3 как можно скорее покажет свои ограничения (плачевная производительность со многими файлами в том же каталоге, постоянная остановка из-за fsync, и т.д.) я использовал XFS в течение многих лет (не может заставить людей архивировать свои письма в подпапках, и я нашел, что XFS единственная файловая система, это и в состоянии легко обработать десятки тысяч файлов в каталоге и не подверженное ужасающему замедлению со временем (да, ReiserFS, я смотрю на Вас.)

  4. Если Вы будете использовать IMAP, ограничите количество кэшируемого соединения в Вашей клиентской конфигурации IMAP (в Thunderbird, то Вы найдете, что при Настройках учетной записи-> желаемая учетная запись-> Настройки сервера-> нажимают на кнопку Advanced справа-> определенный Максимальный номер серверных соединений для кэширования к 1 или 2, или по крайней мере что-то более нормальное, чем значение по умолчанию 5.

  5. При использовании IMAP через некоторую систему веб-почты или другой рассмотрите установку прокси IMAP, иначе Вы вызовете постоянные перелогины из-за природы веб-приложений. Пакет, совместимый с Курьером,-imapproxy.

3
задан 14 May 2009 в 18:59
2 ответа

Казалось бы, что, если прокси настраивается для загрузки баланса, как Вы говорите, и существует только один сервер, на который это может указать на, это иногда, баланс загрузки считает сервер целевого приложения слишком занятым, и дает Вам ту ошибку.

Можно ли соответствовать ошибка, которую Вы видите к какому-либо виду нагрузки на сервер? Существует ли способ вынуть выравнивание нагрузки из уравнения и теста? Можно ли настроить настройки/представление подсистемы балансировки нагрузки их, чтобы видеть, имеет ли это очень консервативные пороги?

1
ответ дан 3 December 2019 в 07:20
  • 1
    Никакая корреляция между ошибками и загрузка. I' ll видят, могут ли администраторы вынуть подсистему балансировки нагрузки из изображения. I' ll также пытаются получить полный файл конфигурации.Спасибо. –  jlpp 14 May 2009 в 03:36
  • 2
    Добавленная конфигурация подсистемы балансировки нагрузки к тексту вопроса. Спрошенные sys администраторы, чтобы попытаться удалить подсистему балансировки нагрузки. –  jlpp 14 May 2009 в 19:00
  • 3
    Администратор Sys говорит мне, что подсистема балансировки нагрузки необходима для аутентификации SiteMinder так мы can' t удаляют это. –  jlpp 14 May 2009 в 21:47

Я подозревал бы, что функция проверки состояния выполняет и решает, что сервер бэкэнда недоступен. Возможно, попытайтесь увеличить значения тайм-аута в конфигурации медицинского средства проверки или отключите ее полностью. С тех пор существует только один сервер приложений для проксирования к, это действительно не вызовет потерянной функциональности.

1
ответ дан 3 December 2019 в 07:20
  • 1
    Спасибо Luke. I' ve попросил, чтобы sys администратор отключил медицинское средство проверки. Сообщит с результатами. –  jlpp 18 May 2009 в 15:56
  • 2
    Отключение медицинского средства проверки кажется для продвижения к ситуации, где, если сервер приложений по-настоящему безразличен, подсистема балансировки нагрузки/proxy/web сервер в конечном счете заметит, что запросы являются not' t возврат и тег сервер безразличен. Это затем начинает возвращать синие/фиолетовые ошибочные экраны. Проблема состоит в том, что, когда сервер приложений становится быстро реагирующим, подсистема балансировки нагрузки все еще возвращает ошибочную страницу. That' s поведение we' ре, видящее теперь. –  jlpp 19 May 2009 в 16:16
  • 3
    Охота, хорошо затем I' m новый из идей. Я вижу это you' ve открыл запрос в службу поддержки, хотя - я жду встречи с тем, с чем возвращается Sun. –  Luke 19 May 2009 в 16:50

Теги

Похожие вопросы