Регистрация

«И это все о ней, или сколько волка ни корми» — Михаил Сусоров об эволюции производительности систем и стоимости ошибок корпоративного ИТ

11 мая 2023 2345 0

Сегодняшние условия российского ИТ-ландшафта требуют немедленных шагов к переходу с западных продуктов на отечественные — и здесь часто приходится «изобретать велосипед», сталкиваясь с проблемами, которые два-три года назад пребывали в «фоне» или не существовали вовсе. Одним из важных критериев успешности перехода становится сохранение или улучшение производительности систем, обеспечивающих критичные для компании бизнес-процессы.

Михаил Сусоров в приведённой ниже статье погружается в историю проблематики и демонстрирует, как можно использовать опыт прошлых лет в решении сегодняшних проблем — например, чтобы показать бизнесу в конкретных цифрах реальную выгоду компании от стабильной производительности систем.

Подробнее мы разберем вопросы сохранения производительности при переходе на отечественные системы в ходе вебинара — не забудьте зарегистрироваться!

И это все о ней или сколько волка не корми

Как известно, в переводе с древнеиндейского слово Windows означает — «белый человек, смотрящий сквозь прозрачное стекло на песочные часы».

В очень недалеком прошлом, в курилке одного очень известного в узких кругах подмосковного мероприятия коллега из транснационального ИТ-гиганта пожаловался на стабильное и многолетнее падение продаж высокопроизводительных систем. Тех, которые еще не штучные суперкомпьютеры, но и уже не обычные сервера. А нечто среднее, выпускающееся серийно.

И меня прямо в той же курилке посетило некоторое дежавю на эту тему. Перед глазами проплыли сначала зеленые терминалы EC-1033, потом машинный зал двухпроцессорной ЕС-1068, более разноцветные дисплеи Vax-9000, промелькнули синклеры-атари-векторы во всем их разнообразии, ДВК и наконец первые «настоящие» PC с «косыми флопами» (и далее со всеми вариациями архитектуры x86 по сей день). Я припомнил, как мы «грызли» уравнения Навье-Стокса на всем вышеперечисленном, что было тогда доступно в разных вариациях. И как каждый запуск расчета на процессоре 80386 аж с целыми двумя мегабайтами памяти занимал часов этак 12-15, если не очень настаивать на точности. Не менее хорошо запомнилось, что ЭВМ единой серии считали эти задачи примерно раз в сто быстрее чем тогдашние РС или раз в сто точнее за то же время. И это несмотря на то, что 80386 процессор со своими 20 Мегагерцами занимался моей персональной задачей не отвлекаясь, а на ЕС обычно висело человек по 200 в круглосуточном режиме.

С тех пор утекло не так уж и много времени и вот настали времена, когда обычные «бытовые» РС догнали по производительности в «бытовых» задачах типа ERP, CRM, MES и тому подобных прикладных задач те самые суперкомпьютеры конца прошлого и начала этого века. Да и сами суперкомпьютеры стали собирать из «бытовых» процессоров и памяти, продающихся на каждом углу. И уже ноутбук с шестиядерным процессором на 4 гигагерца и 128 гигабайт оперативной памяти никого не удивляет. Конечно, остались задачи, в которых вычислительная мощь никогда не бывает лишней (научные расчеты, те же уравнения Навье-Стокса или моделирования ядерных реакций и биржевых рисков). Но вот на бытовом уровне состояние «больше не надо» достигнуто по весьма большому перечню задач. На самом обычном ноутбуке можно монтировать видео высокой четкости, проектировать и рассчитывать параметры довольно сложных конструкций, рисовать картинки в графических редакторах и много чего другого. А на ноутбуке помощнее можно рисовать фильмы, которым позавидует SGI десятилетней давности и 3D модели с вполне промышленной детализацией. И все это все это не будет занимать как раньше многие часы, а будет похоже скорее на online, что наглядно демонстрирует киноиндустрия.

Для оценки масштаба «бедствия» приведу конкретный пример. Лет примерно 10 назад на просторах нашей родины было создано решение для биллинга весьма распространенной на планете услуги для физических и юридических лиц. Полностью наше местное. Смысл задачи прост — фиксируем показания «измерительной линейки» в начале периода и в конце, далее применяем десятка три-четыре различных тарифов и коэффициентов и на выходе имеем сумму к оплате.

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

Да еще и с пристрастием. Результаты довольно продолжительных, почти научных изысканий, удивили даже меня. Время расчета на 10 миллионов абонентов составило примерно 30 минут на двух серверах на сегодняшний день очень похожих на среднего калибра ноутбук. То есть, не сложный расчет говорит о том, что для расчета суммы за эту коммунальную услугу всем жителям нашей планеты (в количестве 8 миллиардов) в течении 30 минут будет достаточно 1500-2000 не самых мощных на сегодня ноутбуков. Или 150-200 серверов среднего уровня. Которые займут один весьма небольшого размера ЦОД.

Решение же от именитого заморского производителя укладывалось с расчетом в два часа полностью загружая двухметровую серверную стойку с количеством процессорных ядер, измеряемых десятками и количеством памяти измеряемом в терабайтах. Стоимость железа отличалась на два порядка. То есть в сто раз.

Можно еще для примера припомнить задачи с расчетом зарплаты на почти полмиллиона сотрудников, сборы консолидированной отчетности со 100 ДЗО и тому подобные задачи, для решения которых в нормальное, с точки зрения бизнеса, время, применялось весьма «ширпотребное» по нынешним временам «железо». То есть тенденция как минимум понятна.

Казалось бы — на текущий момент соотношение цены и производительности имеющейся в широкой продаже компьютерной техники должны удовлетворить 95% потребностей широких слоев потребителей ИТ. И с большим запасом в большей части задач. Но вот на практике вопросы по производительности тех или иных систем возникают с пугающей периодичностью.

Теоретически — это лошадь. А практически — не едет

Для понимания «обратной стороны медали» обратимся к весьма интересному исследованию на эту тему. В котором подробно рассматривается вопрос о зависимости времени отклика системы от параметров «железа». Более подробно можно ознакомиться по ссылке. А показательную табличку я приведу тут.

Компьютеры Отклик (мс) Год Тактовая частота Количество транзисторов
Apple 2e 30 1983 1 МГц 3,5 тыс
TI 99/4A 40 1981 3 МГц 8 тыс
Haswell-E 165 Гц 50 2014 3,5 ГГц 2 млрд
Commodore Pet 4016 60 1977 1 МГц 3,5 тыс
SGI Indy 60 1993 0,1 ГГц 1,2 млн
Haswell-E 120 Гц 60 2014 3,5 ГГц 2 млрд
ThinkPad 13 (ChromeOS) 70 2017 2,3 ГГц 1 млрд
iMac G4 (OS 9) 70 2002 0,8 ГГц 11 млн
Haswell-E 60 Гц 80 2014 3,5 ГГц 2 млрд
Mac Color Classic 90 1993 16 МГц 273 тыс
PowerSpec G405 60 Гц (Linux) 90 2017 4,2 ГГц 2 млрд
MacBook Pro 100 2014 2,6 ГГц 700 млн
ThinkPad 13 (Linux Chroot) 100 2017 2,3 ГГц 1 млрд
Lenovo X1 Carbon 4G (Linux) 110 2016 2,6 ГГц 1 млрд
iMac G4 (OS X) 120 2002 0,8 ГГц 11 млн
Haswell-E 24 Гц 140 2014 3,5 ГГц 2 млрд
Lenovo X1 Carbon 4G (Windows) 150 2016 2,6 ГГц 1 млрд
Next Cube 150 1988 25 МГц 1,2 млн
PowerSpec G405 (Linux) 170 2017 4,2 ГГц 2 млрд
PowerSpec G405 (Windows) 200 2017 4,2 ГГц 2 млрд
Symbolics 3620 300 1986 5 МГц 390 тыс

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

Так же в исследовании справедливо было отмечено, что в нормальном состоянии время отклика системы должно быть сравнимо со скоростью реакции обычного человека которое в среднем, составляет 100-200 миллисекунд. Все что откликается медленнее — вызывает дискомфорт пользователя. И именно поэтому время отклика современных систем находятся как раз в районе среднестатистического физиологического минимума среднестатистического пользователя — меньшее время отклика может оценить только очень узкий круг людей, например кибер-спортсменов.

Дальнейшее сокращение времени отклика систем, экономической целесообразности, соответственно, не имеет. Этот «предел желаний» в 200 миллисекунд и рекомендуется взять в качестве целевого показателя при анализе производительности систем.

Aliena vitia in oculis habemus, a tergo nostra sunt

Собранная за много лет статистика говорит о том, что можно выделить три основных причины «торможения» систем.

Причина первая, проявляющаяся в 2% случаев и условно называемая «проблемы с железом». Сюда входят, например, «оригинальные» настройки BIOS и гипервизоров.

Причина вторая, отвечающая за 3% проблем и условно называемая «архитектурные проблемы». К ним условно относятся архитектуры и настройки прикладных серверов и серверов баз данных.

Ну и в 95% случаев причина заключается в «грамотно» написанном коде системы. На этом моменте можно остановиться подробнее. Выросшая в миллионы раз производительность «железа» в значительном количестве случаев позволила действовать писателям кода по упрощенной схеме создания программ — сначала как можно быстрее получаем функционал и запускаем его в работу (естественно, под хоровое выступление бизнес-пользователей по темам «мы теряем деньги», «этот функционал нужен был год назад», «отчет нужен вот прямо завтра», «если в понедельник не будет — все клиенты разбегутся»). Главное, чтобы этот функционал хоть как-то «шевелился» и на момент сдачи в эксплуатацию быстродействием сильно не раздражал. А уже «потом» планируем занимаемся техническим совершенствованием полученного решения. «Потом» подумаем над масштабированием, производительностью при количестве пользователей больше двух и на другие очень правильные темы. Только вот это «потом» имеет обыкновение растягиваться на годы, если последствия такого «потома» не проявляются в течении короткого периода времени. И проявляются они обычно в двух вариантах.

Первый. Резкое падение производительности. Например, при очередном «улучшении» системы. То есть пришедшие в понедельник на работу пользователи системы по факту ею пользоваться не могут. То есть система вроде как работает, но время отклика системы вызывает массу откликов пользователей. И это не самый плохой вариант развития событий, так как все мероприятия отложенные на «потом» начинают реализовываться в аварийном порядке и иногда даже принимаются меры по предотвращению повторения такого в дальнейшем. Такой вариант проявления «потома» один из самых дешевых, но болезненных и неприятных для бизнеса, с его наступлением обычно начитается этап понимания того факта, что профилактика всегда дешевле лечения, а простой в работе имеет весьма впечатляющую цену.

Второй. Медленная деградация производительности. При этом варианте производительность падает постепенно и не очень заметно для пользователей. Понемногу, не спеша, время отклика растет, выполнение регламентных операций и формирования отчетов то же увеличивается. Все же помнят, что бывает с лягушкой, если ее сначала положить в холодную воду? Вот и тут с течением времени обычный пользователь вдруг обнаруживает, что теперь за время формирования отчета можно сходить на перекур. А еще через полгода — можно еще и чаю попить. А еще через полгода — и пообедать. В этом варианте жалобы пользователей носят массовый характер уже в самом конце, да и некоторая их заинтересованность в такой ситуации то же есть — получить стопроцентное оправдание перекуров и чаепитий удается не каждый день. В какие деньги для организации такая ситуация обходится — посчитаем чуть ниже.

В следующем году мы посадим 100 га овса — нехай зараза подавится

Реакции ИТ-шников на падение производительности, в основном, стандартны. На практике обычно встречается три разновидности.

Разновидность № 1. Залить железом

Способ простой, понятный и очевидный даже финдиректорам и бухгалтерам — раз система «тормозит» — значит нужен сервер побольше, потолще и, естественно, подороже. И ИТ-директор пускается во все тяжкие закупая или арендуя гору «железа» с запасом «производительности» ну хотя бы года на три. Но вот часто получается результат почти обратный ожидаемому — количество процессоров памяти и прочего увеличилось вдвое, а время отклика — сократилось на 10-15%.

Суперсовременное хранилище купили — а отчеты быстрее не формируются. Бывает, что мощность нужна раз в 10-20 больше, чтобы система вообще хоть как-то позволяла работать и не остановить бизнес. Обычно это происходит в вышеописанном варианте № 1 когда времени на выяснение причин падения производительности нет, а работать хоть как-то надо. Или часто наблюдается в окологосударственных компаниях, где «железо» закупали по принципу «на все деньги и сейчас, что бы бюджеты не порезали». В результате имеем классический вариант «стрельбы из пушки по воробьям», то есть замороженные в оборудовании, потраченные амортизацию и эксплуатацию деньги, которые можно было бы использовать в более приличных целях. В других областях деятельности перевозка мешка картошки карьерным самосвалом если и встречается, то намного реже чем в ИТ.

Разновидность № 2. Заткнуть дырки

Если Разновидность № 1 по разным причинам либо не реализуема, либо ее реализация ситуацию не улучшила — переходим к Разновидности № 2, то есть пытаемся привести систему в рабочее состояние в аварийном режиме. Меняются конфигурации и архитектуры, правится код, привлекаются сторонние специалисты и работа продолжается до тех пор, пока крики пользователей не перестают быть слышны в кабинете ИТ-директора. В данной разновидности все познается в сравнении — если расчет себестоимости составлял, к примеру, 48 часов, а в результате выполнения работ было уменьшено до 6 часов — то это же явный успех. Если не знать, что это время можно было сократить до 15 минут... Хотя пользователи оказались полностью удовлетворены результатом в 12 часов...

Разновидность № 3. Борьба с причинами

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

«Его пример другим наука» или из последнего непонятого

Как гуляли — веселились

Оценим примерную стоимость всего этого банкета. В расчет примем:

Сделав несложные вычисления, можно понять, что прямые потери составят в районе 10 млн рублей ежемесячно. Если сюда добавить косвенные расходы вроде излишне употребленного отопления, амортизации, электричества и тортиков — то цифру можно легко удвоить. Инструментов же для сбора времени показа любой системой «песочных часов» и измерений времени отклика на сегодня достаточное количество, поэтому любой финансовый директор может запросто запросить у ИТ нужные показатели и посчитать во сколько денег обходятся проблемы с производительностью на конкретно его предприятии.


Присоедяняйтесь 25 мая в 19:00 к нашему вебинару «ERP-системы 1С: переходим без потерь» с Михаилом Сусоровым.

Нажимая на кнопку "Подписаться", Вы соглашаетесь с условиями Политики в отношении обработки персональных данных и даете согласие на обработку персональных данных