Распределенные компьютерные системы в реальной жизни. История: компания Y.

Это продолжение предыдущего конспекта. 

Был конец 1999, программист работал в компании Y, которая обслуживала финансовые отчеты в Интернете. Web-запрос происходит через один из многочисленных Web-серверов. Тот передает запрос менеджеру нагрузки, а он, в свою очередь, доставляет запрос к одному из четырех серверов отчетов циклическим образом. Сервер отчетов берет информацию из базы данных, для того, что бы сгенерировать отчет.

Вдруг начали происходить странные сбои – серверы отчетов не с того ни с чего начали выходить из строя один за другим: сервер падал, перезагружался, и, через несколько минут снова падал. Это случилось со всеми серваками. При чем, частота поступления запросов не была очень высокой.

Первое, что сделал программист, это включил системы протоколирования и трассировки, которые были деактивированы в конечном продукте.  

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

Далее программист посмотрел протокол сервера нагрузки и увидел, что то все время обращается к одному и тому же серверу. Исходя из этого наладчик сделал вывод, что механизм распределения нагрузки работает неправильно.

Далее программист решил выяснить, какого рода проблема заставляет сервер отчетов перезапуститься.

Сервер отчетов может поддерживать 20 потоков одновременно, и каждый запрос к серверу занимает 1 процесс. Ожидалось, что каждый запрос будет обрабатываться примерно 1-2 секунды. Если все 20 потоков были заняты, и поступал 21 запрос, то он должен быть ожидать освобождение потока 5 секунд. Если время ожидания истекло, то все 20 потоков зависали.

Причина сбоя оказалась в том, что когда один из серверов попал в ситуацию, когда при 20 занятых потока поступал 21, он перезагружался и переставал обслуживать запросы. Но так как скорость поступления запросов оставалась прежней, то на оставшиеся 3 сервера нагрузка увеличивалась, что привело к сбою еще одного сервера. К тому времени, когда закончил перезагрузку первый сервер, останавливался третий. Этот эффект мог продолжаться сколь угодно долго, если скорость поступления запросов оставалась прежней.

При дальнем анализе оказалось, что время обработки запрос почему то увеличилось. Но после перезагрузки SQL-сервера проблема решилась.

Источник: Мэтт Тэллес, Юань Хсих, "Наука отладки".

Продолжение следует.