Бесконечная история, часть III

История одной оптимизации

"Мы увеличили пропускную способность дискового массива на 60%, но лучше от этого не стало" - это было как раз то место, после которого я вышел на сцену. Это была prepaid-система, которая примерно месяц как вылезла за рамки допустимого времени отклика. Все существующие усилия зашли в тупик, и теперь команда думала, каким бы образом произвести тюнинг ядра HP-UX.

Тюнинг ядра HP-UX?

Первый же взгляд на Statspack показал, что вся 64-процессорная система 90% времени проводит в ожидании latch free. Увеличение производительности дисковой подсистемы, в конечном итоге, привело к ещё большей конкуренции за защёлки и увеличению этого ожидания. Ядро HP-UX было определенно далеко от первого, что пришло мне на ум - я попросил возможности взглянуть на приложения.

Немного концепции

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

Как они это сделали

При поступлении вызова, вам необходима информация об абоненте. Система состояла из некоторого подобия очередей, реализованных в виде таблиц. Каждая следующая стадия представляла собой отдельную таблицу, куда попадала запись из предыдущей. Упрощённо говоря, в первую таблицу попадал только номер абонента с некоторой служебной информацией. Во вторую таблицу эта запись попадал уже с идентификатором этого абонента в биллинговой системе, тарифным планом и суммой средств на балансе, после чего удалялась из первой таблицы. И так далее - всего в процессе участвовало 4 таблицы. Горизонтальная масштабиремость должна была достигаться путём увеличения процессов, осуществляющих перенос из одной таблицы в другую.

Система имела по 16 процессов для переноса из одной таблицы-очереди в другую. Разбиение данных происходило просто по фильтрации с условием mod(key, 16), где key - некоторое подходящее числовое поле (например, суррогатный ключ идентификатора абонента). Конечно, вам следует использовать простое число при подобном способе хэширования, но в любом случае проблемы были далеки от выбора одного из операндов у функции mod.

В реальности это означало, что каждый процесс из 16 записей брал только одну - делал в 16 раз больше LIO, чем требовалось. Учитывая высокую нагрузку на систему (все процессы-переносчики практически постоянно были активными), не трудно представить, что часть ожиданий latch free приходилась на cache buffer chains. Ситуация усугублялась так же тем, что в большинстве таблиц у нас было 16 процессов, пытающихся туда писать и ещё 16 процессов, пытающихся оттуда читать. Дальнейшее увеличение количества процессов-переносчиков не давала никакого эффекта, кроме увеличения нагрузки на CPU, в следствии постоянных spin'ов в попытке захватить CBC latch.

Последнее "гениальное" решение проектировщиков завершало картину. Кому-то пришло в голову, что неплохо бы сделать имена таблиц в системе настраиваемыми. В результате, процессы-переносчики работали исключительно через динамический SQL, в придачу осуществляя перенос не более одной записи за раз. Теперь, они добавили ещё и латчи в shared pool.

В результате этих архитектурных решений, 90% времени система просто буксовала на механизмах сериализации. Стоит ли говорить, что разработчики уже начинали рассматривать вариант переписывания части кода на C++, поскольку "судя по всему, Oracle не может с этим работать".

Бесконечная история, часть II

Большинство проектов по решению проблем с производительностью протекают при полном отсутствии информации, какой компонент системы действительно представляет собой проблему. Традиционная практика "fire and forget" очень быстро оборачивается против директора по ИТ, который всё ещё думает, что апгрейд аппаратного обеспечения способен решить все проблемы.

Нет ничего более простого, как исчерпать весь кредит доверия, тратя ресурсы на бесполезные апгрейды. Я видел, как это происходит (и более одного раза).

Достаточно забавно, но спустя год или полтора я, как правило, встречаю тех самых системных интеграторов, выполнявших никому не нужные оптимизации. "Тогда мы увеличили пропускную способность дискового массива на 60%, но лучше от этого не стало", - по крайней мере, после встречи со мной, они знают, почему.

Бесконечная история, часть I

Хьюстон, у нас проблемы!

Спросите меня, как начинают решать проблемы с производительностью. Да, - вы просто начинаете впихивать тонны железа, в надежде, что они исчезнут. Ух. До тех пор, пока вы можете это делать...

Что дальше I

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

Что дальше II

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

Хьюстон, мы падаем!

Здесь я получаю звонок в половину первого ночи. Утром с вещами на работу. В обед лечу за 8000 километров. Масштабы трагедий всегда обратно пропорциональны прошедшему от звонка до вылета времени.

По прибытии на площадку, я как правило наблюдаю что-нибудь вроде 64-ядерного (вы не можете впихнуть больше в один кабинет) SuperDome. Примерно в таком же состоянии находится остальное оборудование - в нём просто нет места, куда ещё можно что-то поставить.

Бой с тенью

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

"Проведённые исследования не выявили наличие проблем в данной подсистеме"

Конечно, я знаю. Deja vu. Но, наверное, это просто связано с тем, что иначе меня бы здесь не было? Если вы не видите своего врага - просто пытайтесь бить куда можете...