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

[dastapov]

Много лет тому назад, в одной далекой галактике войска Императора собирали в космосе очередную Звезду Смерти. Нет, это из другой баечки. Начнем еще раз ...
Много лет тому назад, в одно софтверной компании группа разработчиков работала над очередным Скучным Индустриальным Проектом, который к ним за-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

[webushka.livejournal.com]

Что-то ужасно знакомое :)
Но в той Серьёзной Индустриальной Инсталляции автоматически правился crontab солярки. С добавлением туда что-то типа find /tmp -mmin +10 :)))

[voituk.livejournal.com]

Главное пробел между "/" и "tmp" не поставить - ато мы это тут уже проходили :)

[blacklion.livejournal.com]

Ох, отличная история. Спасибо, порадовали.
Собственно, после телнета к модулю я уже стал подозревать нечто подобное, а после fopen /tmp/... всё стало ясно :)

[dfaw.livejournal.com]

Знакомо.

Напарнику была задача настроить spamassing, точнее прочитать RTFM и довести его до ума, в итоге я полностью апгрейдил весь майл софт, бо он часть снес, а часть так обновил, что лучше бы снес.

[squadette.livejournal.com]

я уже второй раз в жизни оказываюсь искренне удивлён, обнаружив, что операция удаления файла -- совершенно не пренебрежительно дешевая. то есть удаление списка из 10 тысяч файлов на (правда, загруженном) сервере занимает например минут тридцать пять

там конечно все файлы раскиданы по подкаталогам и т. п., и всё же

приходится второй раз писать асинхронную удалялку, что странно

[egorfine.livejournal.com]

Зависит от ОС/ФС. Удаление на ext2 (линукс) - дорогая операция, на UFS (FreeBSD) - дешевая.

Почему так - не знаю.

[dil.livejournal.com]

Угу, только почему-то удаление каталога с 5000 файлов на линуксе с ext2 происходит на порядок быстрее, чем на солярке с UFS. Оно, конечно, машинки физически разные, но обе достаточно современные.

[blacklion.livejournal.com]

UFS на FreeBSD и UFS на Солярке -- это, мягко говоря, разные вещи внутри. Не в смысле disk layout (хотя UFS2 от FreeBSD, которая уже давно по-умолчанию м на диске другая), а в смысле реализации.
Solaris -- это олд-скул UFS, в которой работа с каталогами и инодами -- sync (если система не смонтирована с async), и потому удаление 5000 файлов -- это порядка 15000 записей на диск (5000 раз каталог, 5000 раз битмап инодов, 5000 раз сами иноды -- счётчик уменьшить). Во FreeBSD там softupdates, которые сгруппируют это так, что останется гоооораздо меньше записей -- каталог скорее всего будет писатся один раз, битмап инодов тоже, ну и иноды будут, тут никуда не деться, но иноды, которые в одном блоке сидят будут одним куском писатся, а не ради каждого инода блок заново переписываться...

[egorfine.livejournal.com]

Не понял. Даже на современной солярке работа с каталогами синхронная по дефолту? :-O

[blacklion.livejournal.com]

Да. Никто там ничего в UFS не менял много лет.

Кстати, я в своей оценке еще битмамп блоков забыл -- а это еще 1 запись на каждый файл минимум :)

[egorfine.livejournal.com]

Ну в принципе еще диск свое подкеширует, но это не дело... хотя впрочем, им (девелоперам йадра) виднее.

[blacklion.livejournal.com]

Точнее я смогу отвтеить после 18-го мая, у меня на той неделе (14-18 мая) как раз плотный тренинг по Solaris Kernel Internals, спрошу у препода.

[blacklion.livejournal.com]

Кстати, на таком диком каталоге (десятки тысяч файлов в одном каталоге) и FreeBSD тормозить будет на stat()'ах и созданиях файлов, не смотря на softupdates -- никакой softupdates не поможет от линейного просмотра каталога каждый раз. Тут может помочь dirhash, но тоже костыль.

А вот XFS (с ирикса) или ZFS (с солярки, а теперь и с FreeBSD) пережёвывает такие каталоги как неифк нафик -- как-никак каталоги в б-три.

[egorfine.livejournal.com]

ну видишь, не только фс, но и ос подруливает свое.

Правда, я вот не могу сейчас сказать насчет больших каталогов, но вот большие файлы удаляются моментально на UFS и довольно долго на ext2. Например, кино - может удаляться секунд 3-5 на современном железе.

[blacklion.livejournal.com]

Ага, ага, fastupdate во всеё красе. Файл уже удалён -- а место еще не освободилось и диск шуршит :) Та самая асинхронная удалялка прямо в ядре -- каталог порпатчили, инод пропатчили, а с дисковыми блоками в фоне разбираемся.

[eentropy.livejournal.com]

ОС: MS Windows 2000
FS: NTFS

Удаление одного каталога с миллионом файлов с помощью команды RD - несколько часов. То, что GUI OS с такими объектами не работает вовсе, и вовсе не удивляет.

[ex-mysteelhe377.livejournal.com]

меня тоже прикололо- менеджер для mp3 плеера iRiver версии 2.x - 1,5мегабайта, версии 3.x- уже 30 (!), полуось столько места занимает. Функциональности- полторы функции, косяков- больше, чем функционала... Блин. :(( И качать по дайлапу надо было без докачки. 30 мег, ага. Не то, чтоб я индусов не люблю...:)))

•

[oas.livejournal.com]

А это ребята тупо, чтобы не париться, завернули внутрь него инсталлятор netfx 1.1. По-моему, это я его с таким результатом развинчивал.

Re: •

[(Anonymous)]

и правда. 6 метров полезного груза. Стрелять :))

[ems-viking.livejournal.com]

перешейте иривер, и забудте о менеджере

[(Anonymous)]

Не хочу.

[kastaneda]

В логах никаких ошибок нет, по S.M.A.R.T. выходит, что винт жив-здоров, файловая система тоже без ошибок.

Глупый вопрос - как под популярными OS (Linux, FreeBSD, Solaris) послушать ругань S.M.A.R.T.'а?
Гугль, сволочь, издевается.

[dil.livejournal.com]

ну вот под линуксом -
# smartctl -l error /dev/sda
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged

ну или -a, он там сразу выдаст все, что сможет.

[kastaneda]

О! Спасибо :)

[guest-o.livejournal.com]

У меня смарт прямо в логи пишет. Или если совсем плохо, то прямо руту на мыло жалуется. Fedora Core 6.

[eentropy.livejournal.com]

Нету никакого доверия к S.M.A.R.T по части прогнозирования ошибок. Хуже него только "священный" MTBF, шоб им IBM и Fujitsu подавилось.

индус по имени "Ражалпраграм Наджави"

[slavka.livejournal.com]

[gram|work] про индийский код
[gram|work] Какой самый извращенный способ проверить в условии if () булевскую переменную ?
[gram|work] bool b;
[gram|work] b = false;
[gram|work] if (b == true){...}
[gram|work] Это децкий лепет
[gram|work] ИТАК, ПЕРВОЕ МЕСТО
[gram|work] Знакомый говорит что нашел только что в коде:
[gram|work] if (b.ToString().length < 5){...}

http://bash.org.ru/quote.php?num=66390

Re: индус по имени "Ражалпраграм Наджави"

[cofffe.livejournal.com]

уже испорченный телефон пошел :)"if (b.ToString().Length < 5){...}" C#.Net однако.

[goh-dan.livejournal.com]

Зачотная история

[mds.livejournal.com]

нда. Особенно, если учесть, что в солярке /tmp обычно в памяти (swap), наедаться оно должно было в мелкие дребезги.

[zerkms.livejournal.com]

а сколько всё таки там файлов было? или не считали?
и какая фс?

[dwarkin.livejournal.com]

А в Серьезных Индустриальных Инсталляциях наверное машину бутили раз в недельку-другую, вот /tmp и чистился.

[denizzzka.livejournal.com]

а олдскульный гуй не тормозил что ли?

[guerrero de terracota (from livejournal.com)]

На злобу дня, ибо сам сейчас проект что индусы кодили фиксаю :-(

[cofffe.livejournal.com]

Занятно. Прочитал и зачесались руки написать чистилку $(Temp) под виндой, зараза VS2005 создает там кучу файлов. вида: "_CL_2b2d40dcgl".
(Если кто знает как бороться - буду очень рад.)

[xoma-xoma.livejournal.com]

Ну вот ты сам и ответил ;) -- переодически чистить...

[cofffe.livejournal.com]

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

[xoma-xoma.livejournal.com]

Увы, стандартных методов в винде нет ;)
Разве что написать батник и пускать его в шедулере.... или при перезапуске системы.
А Студия создаёт кучу временных файликов для компилятора или во время компилияции. И, вобще-то теоретически, она должна бы их сама и чистить за собой. Опять же, если её не "сваливать", а нормально закрывать.

•

[oas.livejournal.com]

Поставить опцию «чистить темпы при ребуте»? Group Policy, по-моему.

[kalobyte.livejournal.com]

не далее как в прошлую пятницу была такая же кака
cd и ls не отдавали обратно консоль
ждал секунд 30
времени было в обрез и я списал все на глюки reiserfs
автор понял, какое гавно он написал и убил жену
себя только забыл

[migmit.livejournal.com]

Хорошо им (тоскливо) а вот у нас как сделали самопальную медленную СУБД, так и юзают, хоть колом им по голове... И не изменить никак...

[blinohod.livejournal.com]

Кстати, меня в свое время товарищ gvy ткнул носом в XFS для подобных ситуаций. На большом количестве файлов в каталоге оно работает достаточно шустро. Только это не для солярки решение получается :-)

[blacklion.livejournal.com]

В солярке -- ZFS ничуть не хуже XFS'а.

[avk999]

В другой Большой Индустриальной Системе добрые индусы обернули каждый процессик, запускаемый во время EndOfDay, в shell-скрипт. Начинающийся с #!/bin/sh -x. И его вывод писали в лог. Отдельный по каждому процессу. Тоже было негрустно - солярис при создании нового файлика в каталоге, где их пара сотен тысяч, очень задумывается...

[aldekein.livejournal.com]

+1
идейно. хотя у меня такое же было.... =)

Оффтоп...

[matrixagent.livejournal.com]

В преддверии саммита (а участники саммита посетят мой город, Самару), выключено шифрование у мобильных операторов. На нокиях появился разомкнутый замок, на сонэриках - восклицательный знак в треугольнике... народ истерит по форумам, и зачастую выдает за компетентное мнение _такой_ очевидный бред, что глаза вянут читать.
Нельзя ли рассказ небольшой получить, что и как _в действительности_ происходит? Спасибо :)

Дополнение про индусов

[crazy-daemon.livejournal.com]

Давно уже волновала лучшие умы нашей конторы проблема - почему Oracle Reports на Linux стартует на полминуты дольше, чем на винде? Из-за этого даже в своё время от его использования отказались.

И вот теперь британским учёным (в моём лице) удалось приподнять завесу тайны:


(gdb) disassemble rxmrun rxmrun+50
Dump of assembler code from 0x40398cd0 to 0x40398d02:

... (не очень интересно) ...
0x40398ce9 <rxmrun+25>: push 30
0x40398ceb <rxmrun+27>: call 0x8054eb8 <sleep>

То есть кто-то из индусских жрецов Оракла просто написал
sleep (30);
Интересно бы посмотреть в его однопиксельные глаза и задать ему пару вопросов.
(c)http://vnaum.livejournal.com/9731.html (http://vnaum.livejournal.com/9731.html)

Commandline limit

[vag-vagoff.livejournal.com]

Странно, что * убралось в лимит памяти на командную строку. Или в солярисе его нет? Наверно, лучше было бы (mv /tmp /tmp.old; mkdir /tmp; rm -rf /tmp.old)