Сервера стояли 12 дней без нагрузки — было всё ок. Как нагрузка стала появляться — началось.
Хрен вот знает, не заметил там перегрева. Кстати, по питанию тоже вряд ли. Полтора десятков таких серверов на гораздо большей нагрузке себя ок чувствуют. :)
Т.е вы их таки приобрели в одно время.... ????
Если так .... тогда имеет смысл смотреть на железо, может быть там из одной партии битая память .... или Матеря глючные какие-то.... тут уже ядро не ядро... будет виснуть....
На счет точек ничего не скажу, но вот такие вот зависания системы как вы говорите я ловил при следующих случаях:
1) Включенное ACPI.
2) Недостаточное количество питания. (Например в тачке много винтов и в момент какого-то всплеска их активности просто виснет тачка, причем именно виснет, а не отключается... как-то так).
3) Перегрев.
Мой вопрос к вам заключается в следующем: Эти 14 серверов о которых идет речь, они как появились ? Все одним днем ? или вы сперва взяли 1 много лет назад , потом еще и еще и сейчас их 14 и есть проблема? Либо же с момента первого сервера проблема? Потому как действительно на таком количестве + разных ядрах выглядит весьма странно, хотя не буду удивлен если это Java уничтожает так сервер .... имел когда-то дело с Tomcat... так ему и 30 гиг памяти это тьфу.... а каталина это ваще зло :D
Вполне может быть , все что сказали выше и помогло бы, но я уже увеличил и все такое ...... может версия не та... но работало раньше нормально (с слов владельца), пока приостановили разбирательство, перешли на apache, понаблюдаю, там будет видно.
А в этот раз получил описанный выше "HTTP/1.1 504 Gateway Time-out" на стороне курла. При этом , проверялка трогает сайт с двух разных мест, в одно и то же время одна ошибка (интервал 1 минута).
iHead: max_execution_time работает не так, как некоторые ожидают :)
в Unix/Linux он ставит лимит на время, которое скрипт съест у процессора (ITIMER_PROF).
т.е. "обычный" sleep или различные задержки при получении ответа от внешних сервисов не учитываются в этом времени. а это значит, что 502 легко можно словить - nginx просто закроет подключение к бэкенду.
Что-то я не совсем уловил суть, max_execution_time настроено в PHP, стало быть PHP процесс лимитируется, если он выходит за лимиты, об этом же должно быть сообщение какое-то :D ?
Nginx логи дает, но они как вы понимаете не многое поясняют :D типа PHP закрыло соединение :D
temniy: Зачем вип, вот отличные VDS, с отличной поддержкой, рекомендую!
В базовое бесплатное администрирование входит -
1. Первичная установка ОС на серверы.
2. Сброс административного / root пароля операционной системы для заказов VPS.
3. Добавление дополнительных IP на сервер.
4. Настройка бекапов (резервного копирования), в т.ч. на удаленные серверы(в случае покупки доп. места на нашем бекап сервере)
5. Установка стандартных модулей PHP/apache/nginx.
6. Установка стандартного ПО из репозитариев.
7. Обновление ОС, модулей PHP и стандартного ПО из репозитариев.
8. Установка Zend Optimizer/Ioncube.
9. Базовый тюнинг mysql/apache/nginx под нагрузки проекта.
В принципе - этого более чем достаточно обычно.
Остальное - разовые работы по администрированию +20 евро/час.
Поддержка отвечает моментально!
Странно, а у нас пункты 1,4,5,6,7,8,9 входят в процесс установки....
Привет!
Сервера стояли 12 дней без нагрузки — было всё ок. Как нагрузка стала появляться — началось.
Хрен вот знает, не заметил там перегрева. Кстати, по питанию тоже вряд ли. Полтора десятков таких серверов на гораздо большей нагрузке себя ок чувствуют. :)
Т.е вы их таки приобрели в одно время.... ????
Если так .... тогда имеет смысл смотреть на железо, может быть там из одной партии битая память .... или Матеря глючные какие-то.... тут уже ядро не ядро... будет виснуть....
На счет точек ничего не скажу, но вот такие вот зависания системы как вы говорите я ловил при следующих случаях:
1) Включенное ACPI.
2) Недостаточное количество питания. (Например в тачке много винтов и в момент какого-то всплеска их активности просто виснет тачка, причем именно виснет, а не отключается... как-то так).
3) Перегрев.
Мой вопрос к вам заключается в следующем: Эти 14 серверов о которых идет речь, они как появились ? Все одним днем ? или вы сперва взяли 1 много лет назад , потом еще и еще и сейчас их 14 и есть проблема? Либо же с момента первого сервера проблема? Потому как действительно на таком количестве + разных ядрах выглядит весьма странно, хотя не буду удивлен если это Java уничтожает так сервер .... имел когда-то дело с Tomcat... так ему и 30 гиг памяти это тьфу.... а каталина это ваще зло :D
Вполне может быть , все что сказали выше и помогло бы, но я уже увеличил и все такое ...... может версия не та... но работало раньше нормально (с слов владельца), пока приостановили разбирательство, перешли на apache, понаблюдаю, там будет видно.
Вроде как известный и хорошо зарекомендовавший себя сервис не должен заниматься такими глупостями.
Забаньте все их сети... делов то...
5 серверов летают работают.. идентичные..
Тоже с 3мя винтами в Raid-0 ?
Если так, то причем же тут mdadm ? :) Явно проблема в контролере, винт вы вроде меняли , то же самое....
Может быть SATA кабель не очень хороший?
Хороший совет на тему 4х винтов для теста... Если у вас есть еще 1 ... попробуйте собрать Raid-0 из 4х дисков, проверим вариант чередования записи...
А что если добавить в огонь вот такое:
2013/09/06 04:04:17 [error] 2880#0: *127477 upstream timed out (110: Connection timed out) while reading response header from upstream, client: x.x.x.x, server: **********.ru, request: "HEAD / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "*************.ru"
Просто забираю Header через Curl.
Стало быть PHP не при делах? Или таки при делах? :)
В нормальном случае получаю такой ответ:
HTTP/1.1 200 OK
Server: nginx/0.7.67
Date: Fri, 06 Sep 2013 00:21:41 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
X-Powered-By: PHP/5.3.3-7+squeeze3
Set-Cookie: OTtx_2132_saltkey=aRF5iVS7; expires=Sun, 06-Oct-2013 00:21:41 GMT; path=/; httponly
Set-Cookie: OTtx_2132_lastvisit=1378423301; expires=Sun, 06-Oct-2013 00:21:41 GMT; path=/
Set-Cookie: OTtx_2132_sid=964Dzh; expires=Sat, 07-Sep-2013 00:21:41 GMT; path=/
Set-Cookie: OTtx_2132_lastact=1378426901%09index.php%09; expires=Sat, 07-Sep-2013 00:21:41 GMT; path=/
А в этот раз получил описанный выше "HTTP/1.1 504 Gateway Time-out" на стороне курла. При этом , проверялка трогает сайт с двух разных мест, в одно и то же время одна ошибка (интервал 1 минута).
Может какие-то приколы чередования записи?
При двух винтах все просто, при трех уже интересней :D
При тестировании через RAID ... тест то уже проходит через raid0. Стало быть контроллер на три винта разделяет запись.... может не удается догрузить?
max_execution_time работает не так, как некоторые ожидают :)
в Unix/Linux он ставит лимит на время, которое скрипт съест у процессора (ITIMER_PROF).
т.е. "обычный" sleep или различные задержки при получении ответа от внешних сервисов не учитываются в этом времени. а это значит, что 502 легко можно словить - nginx просто закроет подключение к бэкенду.
Что-то я не совсем уловил суть, max_execution_time настроено в PHP, стало быть PHP процесс лимитируется, если он выходит за лимиты, об этом же должно быть сообщение какое-то :D ?
Nginx логи дает, но они как вы понимаете не многое поясняют :D типа PHP закрыло соединение :D
Зачем вип, вот отличные VDS, с отличной поддержкой, рекомендую!
В базовое бесплатное администрирование входит -
1. Первичная установка ОС на серверы.
2. Сброс административного / root пароля операционной системы для заказов VPS.
3. Добавление дополнительных IP на сервер.
4. Настройка бекапов (резервного копирования), в т.ч. на удаленные серверы(в случае покупки доп. места на нашем бекап сервере)
5. Установка стандартных модулей PHP/apache/nginx.
6. Установка стандартного ПО из репозитариев.
7. Обновление ОС, модулей PHP и стандартного ПО из репозитариев.
8. Установка Zend Optimizer/Ioncube.
9. Базовый тюнинг mysql/apache/nginx под нагрузки проекта.
В принципе - этого более чем достаточно обычно.
Остальное - разовые работы по администрированию +20 евро/час.
Поддержка отвечает моментально!
Странно, а у нас пункты 1,4,5,6,7,8,9 входят в процесс установки....
Поставил одну минуту, все равно мало вероятно , что это связано.
Я че-то подумываю на апач откатиться ..... Не такая уж там и нагрузка что бы php умирало вот так вот... :(
---------- Добавлено 05.09.2013 в 23:05 ----------
Дело в том, что Nginx в пиковой точке за сутки обслуживает около 400 конектов....
А среднее число за сутки.... ~180.....
Не ясно, неужели это так много :D И где ошибки блин !!! ?:)