Не буду голословным, расскажу маленькую поучительную историю из жизни Селектела: Довольно долго мы использовали python 2.4 (по-умолчанию в centos 5.5). Программисты много канючили и хотели python 2.6, потом грязными хаками (использованием библиотек, которые работают только с 2.6+) практически предъявили ультиматум. После первичного тестирования, было принято решение о принятии 2.6 в рабочую среду.

Большинство наших сервисов реализовано по принципу easy fall — как только программе что-то не нравится, она тут же (контролируемо) завершается и перезапускается внешним сервисом перезапуска. Это решает проблему очень обширной логики обработки временных ошибок (недоступности базы данных, нехватки места и т.д.) и смены управляющих (смена мастера в кластере, в пуле, смена адреса в файле конфигурации т.д.). Одна из программ зависела от мастера пула (который один в пуле) и на остальных серверах пула (слейвах), обнаружив, что мастера нет, спокойно завершалась, перезапускалась (с задержкой) и снова завершалась. Если мастер менялся, то программа на старом мастере завершалась и переходила в режим ожидания, а на новом с небольшой задержкой начинала работать.

На Python 2.4 оно работало замечательно. Пришёл python 2.6… И мы обнаружили значительное потребление процессрного времени простаивающей системой. Виновником оказался именно python2.6 — он стартовал (вместе с новыми библиотеками) существенно дольше, чем python 2.4.

С точки зрения программиста: что за хрень?
С точки зрения системного администратора: обновили ПО на новую версию — огребли неожиданных проблем.
http://habrahabr.ru/blogs/sysadm/114338/...

#otggoi

2 comments recommend bookmark subscribe