Кейс

Кейс: збой пасля доўгай працы, прасочаны да ўцечкі дэскрыптараў

Тэхнічны кейс: збой, які праяўляўся толькі праз месяц працы, мы звузілі да расследавання ўцечкі дэскрыптараў, упарадкаваўшы кропкі назірання і пашырыўшы журналы.

Агляд кейса

Гэта кейс пра праграму для Windows, якая нечакана падала толькі пасля прыкладна месяца бесперапыннай працы. Мы пачалі з упарадкавання кропак назірання і ў выніку звузілі расследаванне да ўцечкі дэскрыптараў. Галоўнае ў гэтым кейсе — не толькі сама прычына, але і тое, што мы вырашылі, якія назіранні трэба наладзіць у першую чаргу.

Сімптомы

  • Збой не з’яўляецца за некалькі дзён, а праяўляецца толькі пасля доўгай працы
  • Па адной толькі форме, у якой з’яўляюцца выключэнні, цяжка зразумець, ці гэта ўцечка
  • Збой бывае толькі на месцы эксплуатацыі, а на камп’ютары распрацоўшчыка ўмовы ўзнаўлення даводзіцца скарачаць

Абмежаванні

  • Чакаць узнаўлення месяцамі нерэальна
  • Гэта звязана з паўторным падключэннем камеры і сцэнарыямі збою, таму журналаў асноўных сцэнарыяў недастаткова
  • Трэба мець магчымасць пастаянна назіраць, якія рэсурсы растуць

Што мы назіралі

  • Heartbeat па Handle Count, Private Bytes і Thread Count
  • Журналы межаў: пачатак сесіі, паўторнае падключэнне і завяршэнне
  • Журнал жыццёвага цыкла (lifecycle log), у якім create/open/register спалучаны з close/dispose/unregister

Як мы лакалізавалі прычыну

Спачатку мы не сталі шукаць «збой пры доўгай працы» ў такім выглядзе, а звялі ўзнаўленне да сцэнарыяў збою вакол паўторнага падключэння і timeout. У выніку мы вырашылі, што больш абгрунтавана падазраваць уцечку дэскрыптараў, а не ўцечку памяці, і засяродзілі назіранні на гэтым.

Што мы палепшылі

  • Дадалі пункты маніторынгу, каб можна было сачыць не толькі за момантам збою, але і за тэндэнцыяй росту
  • Упарадкавалі журналы межаў, каб лягчэй было прасачыць, які кампанент адкрыў рэсурс і які закрыў
  • Аформілі вынікі расследавання так, каб іх было лёгка перадаць у наступную інфраструктуру тэставання сцэнарыяў збою

З якімі паслугамі звязаны гэты кейс

Гэты кейс звязаны з двума напрамкамі: расследаваннем дэфектаў і аналізам першапрычын, дзе лакалізуюцца збоі, якія праяўляюцца толькі пасля доўгай працы, і распрацоўкай праграм для Windows, дзе журналы, паўторнае падключэнне і назіранне ў эксплуатацыі наладжваюцца з боку рэалізацыі.

Звярніцеся па кансультацыю

Калі ў вас ёсць праблема, блізкая да зместу гэтай старонкі, параіцеся з намі і напішыце, у якім вы цяпер становішчы і якая падтрымка вам патрэбна.

Назад на галоўную