Проблема критичного падіння продуктивності ІТ системи в годину пік, за умови нестачі оперативних серверних ресурсів

Недавні події, пов'язані з найбільшим енергетичною кризою в Москві наштовхнули мене на думку про написання цієї статті. На перший погляд здається, що спільного між енергетичною мережею та промислової ІТ системою? Спільного дуже багато. У першу чергу, це розподілені системи з великою кількістю користувачів. У цих систем схожа мережна топологія, схожі проблеми та методи їх дозволу. Я не буду вдаватися в усі подробиці, опишу основні моменти, що стосуються нерівномірного навантаження на систему за часом, а простіше кажучи, про «Години пік».

В енергетичних системах як втім, і в ІТ системах стоять схожі проблеми обробки нерівномірного навантаження на системи за часом. З одного боку не ефективно витрачати великі гроші на модернізацію обладнання, якщо подібна система постійно завантажена в кілька разів менше своєї максимальної робочої потужності.

З іншого боку просто усереднювати значення завантаження і порівнювати з максимальною потужністю системи і на підставі цього робити висновки про ефективність системи в даному випадку категорично не можна. Справа в тому, що навіть невелике перевищення навантаження щодо максимальної потужності системи може призвести або до відключення автоматикою, або до виходу з ладу обладнання.

На допомога тут приходять автоматизовані системи дозволяють розподіляти навантаження між підсистемами. Таким чином, збільшується загальна ефективність використання. Але тут є і негативні моменти. Якщо вийшла яка небудь з підсистем з ладу і при цьому потоки не були перенаправлені правильно (хоча іноді це не має значення, просто ресурсів не вистачає в будь-якому з напрямів) у цьому випадку є велика ймовірність ланцюгової реакції відключення або виходу з ладу підсистем. Відбувається ситуація, коли підсистема працює на межі своїх можливостей, а плюс до цього, на неї перемикають додаткове навантаження у вигляді підключень користувачів що вийшла з ладу іншої підсистеми. Після перевищення порога навантаження відбувається аварія або автоматика відключає підсистему і попередня ситуація відбувається з наступною підсистемою.

В вищеописаної ситуації необхідно вчасно прийняти рішення про відключення певної кількості користувачів. Чим раніше буде прийнято це рішення, тим меншими втратами можна обійтися. Дане рішення складно прийняти без відсутність ефективних інструментів моніторингу. Адже потрібно зрозуміти кількість користувачів, яких необхідно відключити. Якщо відключити занадто мало то цей «снігова куля» не вдасться зупинити. Відключення занадто великої кількості користувачів погано саме по собі. Відключати користувачів потрібно не просто по кількості, а бажано за пріоритетами. Наприклад, важливі об'єкти повинні бути відключені в останню чергу.

В ІТ системах обладнання хоч і не виходить з ладу, але аналогії можна навести ті ж самі. Користувачам за великим рахунком не важливо чому ІТ система втратила частину функціональності, або не працює взагалі. Сталося це тому, що сервер вийшов з ладу, або тому, що серверні потужності перевантажені, - результат один і той же - система не функціональна (по крайней мірою в повному обсязі). Коли подібна ситуація може статися в ІТ системах? По-перше, це відбувається виключно в час пік, коли запас міцності серверних потужностей невеликий. Не буду розповідати про принципи оптимізації алгоритмів роботи SQL сервера з даними. Просто поділимо частина інформації і частина серверних ресурсів на оперативні і не оперативні.

З точки зору продуктивності ІТ систем важливо, якою кількістю вільних оперативних ресурсів має в своєму розпорядженні сервер. Якщо на обробку запиту сервером оперативних ресурсів вистачає, то він буде виконаний з нормальною швидкістю. У випадку, коли вільних оперативних ресурсів немає, то цей же самий запит буде оброблений за набагато більший період часу. Під вільними оперативними ресурсами можна розуміти, наприклад, обсяг вільної оперативної пам'яті (але не тільки).

При використанні довгих, що зачіпають велику кількість ресурсів, транзакцій сервер займає під їх обслуговування, певну кількість оперативних ресурсів. Це обумовлюється умовою цілісності транзакцій. При паралельної обробці великої кількості довгих транзакцій може наступити момент, коли загальна продуктивність сервера впаде, і більшість серверних операцій стане виконуватися повільніше. При розборі таких ситуацій не можна не враховувати блокувальний механізм MS SQL сервера. Причиною тривалого інтервалу часу обробки транзакції може стати неправильний або неефективний блокувальний механізм. У разі якщо в транзакції зустрічається блокування, то ця транзакція стає в чергу і буде опрацьована, коли заблокований ресурс стане доступний. Заблокований ресурс звільняється, як правило, коли закривається інша транзакція, яка його захопила.

Таким чином, у нас може вишикуватися певна чергу транзакцій, які не можуть бути закриті і оброблені внаслідок роботи блокувального механізму. Кожна відкрита транзакція, як вже говорилося раніше, забирає певний кількість оперативних ресурсів. У випадку, коли ця черга досягне більшого розміру, оперативних ресурсів може не залишитися. Почнеться загальна деградація продуктивності. При цьому ця черга в більшості випадків буде тільки збільшуватися, тому що нові запити від користувачів продовжують надходити, а продуктивність впала.

Цю ситуацію можна вирішити, тільки прийнявши вчасно рішення про відключення певної кількості користувачів, або ж про обмеження вхідного інформаційного потоку. Чим раніше буде прийнято це рішення, тим менше виросте чергу і менше користувачів необхідно буде відключити. Користувачів потрібно відключати на підставі аналізу. Їх не повинно бути занадто мало інакше не вдасться розібрати чергу і таким чином звільнити необхідне кількість оперативних ресурсів. У цьому разі невеликої черговий сплеск активності може збільшити вхідний інформаційний потік і ситуація повториться знову. Відключати користувачів повинні мати певний пріоритетом. Наприклад, головному бухгалтеру, напевно, не сподобається що ви його відключили в момент обробки важливою транзакції, у той час як секретар успішно проводив документ який міг би запросто бути проведеним ввечері. Як правило, в самому наявність черги оброблюваних транзакцій в MSSQL нічого поганого немає. Погано тоді коли розмір цієї чергу перевищує певний поріг.

Стандартного механізму вирішення подібної ситуації в MSSQL немає, єдиний механізм - це механізм ескалації блокувань, коли сервер сам приймає рішення про збільшення рівня блокування в разі її дуже маленькою шорсткого. Подібний механізм не дозволяє вирішувати проблему в повному обсязі.

Для ефективного вирішення даної проблеми необхідно наявність розвинених засобів моніторингу систем, коли оперативно збирається інформація про наявність вільних серверних ресурсів. Також необхідні кошти нотифікації, які дозволять отримати відповідальному співробітнику інформацію про критичну ситуацію максимально оперативно. Визначити пріоритет транзакції можна, реалізувавши нескладний додатковий протокол. Фактично необхідно на початку «важливих» транзакцій на додаткову таблицю записувати відповідність між ступенем що визначає пріоритет і унікальним ідентифікатором процесу (@ @ spid). Після цього відключення сесій можна буде робити більш ефективно і з меншими ризиками.

Як визначити кількість користувачів, яких необхідно відключити? Припустимо, вся черга складає близько 30-і користувачів. Скільки користувачів потрібно відключити? Десять, п'ятнадцять, а може і всі двадцять? На жаль універсального алгоритму не існує. Це залежить як правило від специфіки ІТ системи. Тут необхідно знайти тонкий баланс.

Як часто виникають подібні ситуації? Тут все визначається ймовірністю виникнення подібної ситуації. На ймовірність впливають такі основні фактори: оперативних обсяг вільних ресурсів (природно залежить від потужності серверного обладнання), обсяг вхідного інформаційного потоку, блокувальний механізм (точніше специфіка його використання в поточної БД), час обробки транзакцій і т.п. Виникає ця ситуація досить рідко.

Найбільш актуальні подібні ситуації будуть для 1С 8.0. тому що там блокувальний механізм відрізняється від блокувального механізму 1С 7.7. Причиною може стати як несподіваний сплеск активності учасників (всі одночасно почали проводити документи), а також ситуація коли був запущений какой то специфічний великий звіт або відкрита довга транзакція. Тривало заблокований ресурс, через який проходить більшість транзакцій теж може спровокувати подібну ситуацію.

Ось один з підходів до ідентифікації і відключення цих процесів. Найпростіший варіант - відключення сесій з відкритими блокуваннями (у такому варіанті буде відключено надто багато користувачів):

declare @ str char (4000)

declare @ Spid char (20)

declare Mylog cursor local fast_forward for

select Spid from sysprocesses where (kpid> 0 or blocked> 0) and spid @ @ spid

open Mylog

fetch Mylog into @ Spid

while (@ @ fetch_status-1)

begin

set @ str = 'kill' + rtrim (@ Spid)

select @ str

exec (@ str)

fetch Mylog into @ Spid

end

close Mylog

deallocate Mylog

Виникає питання, а чи можна взагалі обійтися від відключень? Та це можливо. Для цього в блокувальний механізм необхідно враховувати наявність вільних ресурсів. У випадку, якщо їх недостатня кількість, то необхідно в алгоритмі не давати відкривати транзакцію, або, принаймні, захоплювати велику кількість ресурсів до тих пір, поки черга не зменшиться до прийнятної величини. У кожної транзакції, природно, неефективно в онлайн перевіряти наявність вільних ресурсів. Саме тому для реалізації даної схеми необхідний окремий менеджер, який буде це робити в фоновому режимі і видавати інформацію сесій користувачів за запитом.

Компанія SoftPoint пропонує як розвинені засоби моніторингу подібних ситуацій, так і реалізацію блокувальних протоколів враховують ймовірність виникнення подібної ситуації.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://klerk.ru/