новости
статьи
.PRIcall

troubleshooting – дело тонкое

Много лет тому назад, в одной далекой галактике войска Императора собирали в космосе очередную Звезду Смерти. Нет, это из другой баечки. Начнем еще раз ...

Много лет тому назад, в одно софтверной компании группа разработчиков работала над очередным Скучным Индустриальным Проектом, который к ним за- outsource-или из Индии.

Основной задачей проекта было взять Большую Индустриальную Систему и заменить в ней "толстого клиента" на веб-GUI. Чтобы, так сказать, в духе времени обновить порядком устаревший интерфейс. С серверной стороны планировался код на яве, который при помощи самопального протокола общался с основными модулями системы, написанными на С++ под Solaris. Не смущайтесь, зевайте-зевайте. Я тоже всегда зеваю, когда мне интересно ;) Чтобы можно было нормально тестироваться, на какой-то мелкий 1U сервер был подставлен Solaris под Intel, и на нем развернута основная часть системы. После чего началась работа над веб-GUI. Долго ли, коротко ли, дошло дело до того, что GUI можно было пытаться использовать и даже получать через него реальные данные от основных модулей системы. Всю новую функциональность разработчики, понятное дело, тут же проверяли в деле.

Через какое-то время GUI вырос и начал ощутимо тормозить. Разработчики почесали репу и сказали: "Ага! Это у нас неэффективное внутренне представление данных на сервере!". И переписали его. Ура, GUI стал просто летать!

Правда, добавили еще пять-десять фич, и GUI опять начал тормозить. Разработчики опять почесали репу и сказали: "Ага! Это у нас тормознутый persistent layer на сервере!". И оптимизировали его. Выжали процентов 20% производительности.

Правда, дописали еще пару фич, и GUI опять начал тормозить. Разработчики почесали репу, почесали репу еще раз, скурили все сигареты и сказали: "Ага! Это у нас хреновая архитектура! Ну, ща мы ее за-refactor-им!". И сделали refactoring. Выжалось еще процентов 10%. А должно было сильно больше.

Тут разработчики взяли в руки профайлер, и увидели, что самые большие тормоза - в тот момент, когда мы по самопальному протоколу поверх TCP/IP получаем данные из одного из основных модулей системы. Ага. Дальше разработчики взяли в руки telnet, соединились с этим модулем и убедились - действительно тормозит. Хотя по идее тормозить там было особенно нечему - в данном конкретном случае основной модуль должен был передать что-то очень простое, вроде локального времени на том сервере, где он работает.

Тут разработчики взяли в руки truss и стали трассировать основной модуль системы (так как его исходников им не дали). И увидели, что тормоза происходят в момент вызова fopen(tmpfile, "r"), где tmpfile - что-то вроде /tmp/xyz.6787876.

Разработчики удивились и пошли в /tmp. Там они сделали touch somefile. Елки, натурально тормозит на создании пустого файла. И rm somefile (удаление, стало быть) тоже тормозит. В логах никаких ошибок нет, по S.M.A.R.T. выходит, что винт жив-здоров, файловая система тоже без ошибок. Мистика какая-то...

И тут кто-то случайно запустил ls. И очень удивился, не увидев результата. То есть вообще никакого результата. Даже более того - не увидев командного промпта. То есть, набираем ls, нажимаем ввод и тишина. Пять секунд тишина, десять - тишина, минута - тишина, 3 минуты - тишина... По прошествии 5-10 минут ls стал выдавать результат... Оказалось, что индусские авторы основного модуля системы не имели привычки удалять за собой временные файлы. И их накопилось в /tmp совершенно неприличное количество. Настолько неприличное, что обновление директории при создании нового файла занимало от нескольких до десятка секунд.

Разработчики запустили xargs -i * | rm {} и ушли с горя напиваться. С другой стороны - если бы не этот баг в чужом коде, фиг бы они нашли время для всех оптимизаций и рефакторинга.

Остается только догадываться, как это умудрялось работать в Серьезных Индустриальных Инсталляциях.



Дмитрий (_adept_) Астапов
обсудить статью
© сетевые решения
.
.