Всем привет! Меня зовут Виктор, и я программист. Восемь лет работаю в команде Т-Банка и все это время вместе с коллегами занимаюсь проектом «Т-Телефония». Моя команда разрабатывает сервисы, которые обеспечивают голосовую коммуникацию внутри и вне банка. 

Звонки — один из основных способов связи с нами, поэтому система критична для бизнеса с высоким требованием к доступности. Она обрабатывает более 2 млн звонков в день. Если происходит сбой в любой пользовательской системе и нашим клиентам плохо, количество звонков сразу увеличивается, а нагрузка на систему повышается в два-три раза.

Когда мне прилетела первая задача с дампом, единственным инструментом, который я знал, был WinDbg. Я потратил несколько дней, чтобы хоть немного разобраться в нем. С развитием проекта приходилось все чаще снимать дампы, и теперь я знаю о них намного больше.

В статье покажу, что такое дампы, какие есть инструменты для работы с ними и какие у них особенности, покажу наши примеры проблем, расскажу, как мы их решали.

Всем привет!

Я работаю в Тинькофф, в проекте «Тинькофф Телефония». Наша основная задача — организация IP-телефонии внутри компании и за ее пределами. В день через нас проходит несколько миллионов звонков. Всей этой кухней занимаются около 10 сервисов. 

В какой-то момент мы столкнулись с проблемой: во время релиза сервисы останавливаются неприлично долго. Нас это печалило, поэтому мы приняли решение прокидывать везде и всюду CancellationToken. 

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

В один прекрасный день терпение лопнуло, и мы с Женей Мишустиным и Кириллом Марковым накинулись на эту проблему: Женя с Кириллом ловили и анализировали дампы, а я занимался поиском причин такого поведения.

В этой статье хочу рассказать о том, какой интересный подводный камень таит в себе CancellationTokenSource и как это связано с нашими «утечками» памяти.