?

Log in

No account? Create an account
dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
Как понять, что в коде много багов? - Это когда фиксишь их нечаянно ... 
25th-Apr-2007 11:42 pm
Много лет тому назад, в одной далекой галактике войска Императора собирали в космосе очередную Звезду Смерти. Нет, это из другой баечки. Начнем еще раз ...
Много лет тому назад, в одно софтверной компании группа разработчиков работала над очередным Скучным Индустриальным Проектом, который к ним за-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 {}" и ушли с горя напиваться. С другой стороны - если бы не этот баг в чужом коде, фиг бы они нашли время для всех оптимизаций и рефакторинга.

Остается только догадываться, как это умудрялось работать в Серьезных Индустриальных Инсталляциях.
Comments 
26th-Apr-2007 06:13 am (UTC)
Точнее я смогу отвтеить после 18-го мая, у меня на той неделе (14-18 мая) как раз плотный тренинг по Solaris Kernel Internals, спрошу у препода.
This page was loaded Nov 12th 2019, 11:43 am GMT.