Dmitry Astapov (_adept_) wrote,
Dmitry Astapov
_adept_

Как понять, что в коде много багов? - Это когда фиксишь их нечаянно ...

Много лет тому назад, в одной далекой галактике войска Императора собирали в космосе очередную Звезду Смерти. Нет, это из другой баечки. Начнем еще раз ...
Много лет тому назад, в одно софтверной компании группа разработчиков работала над очередным Скучным Индустриальным Проектом, который к ним за-outsource-или из Индии(!).

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

Чтобы можно было нормально тестироваться, на какой-то мелкий 1U сервер был подставлен Solaris под Intel, и на нем развернута основная часть системы. После чего началась работа над web 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 {}" и ушли с горя напиваться. С другой стороны - если бы не этот баг в чужом коде, фиг бы они нашли время для всех оптимизаций и рефакторинга.

Остается только догадываться, как это умудрялось работать в Серьезных Индустриальных Инсталляциях.
Tags: баечки
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 46 comments