Архив метки: .NET Core

Сказ о .NET Core и ошибке его package downgrade

vimdiffЗа последние шесть или около того недель Майкрософт, конечно, отличились: выпустили целую кучу версий .NET Core 2.1 SDK (Preview 2, Release Candidate 1, Early Access, RTM), которые мы все и попробовали. Так как всё происходило в спешке, к выходу финальной версии мой кластер CI серверов выглядел как зоопарк. Там были RC1 сервера, выглядевшие как Early Access. EA сервера, пытающиеся быть похожими на RTM. Ну как и не упомянуть тот единственный RTM сервер, который старался быть похожим на всех. Ну а что, бывает.

Проблемы начались тогда, когда я попытался разгрести этот бардак и поудалять пререлизные машины, поубирать P2, RC1 и EA SDK теги с релизных веток, ну и выкатить свежие билд-сервера с новейшим и стабильным .NET Core SDK 2.1 на них. Ну и ничего, естественно, на них не скомпилировалось.

Читать далее Сказ о .NET Core и ошибке его package downgrade

Дебаггинг .NET Core приложения из командной строки в Linux

дебаггинг из командной строки

Миллион лет тому назад, ещё в университете, я делал курсовую по Unix на C++ и в какой-то момент мне пришлось дебаггить всё это третьекурсное великолепие из командной строки. Это было офигенно. И ощущение тотальной гикнутости происходящего, и поразительная эффективность процесса. Оказывается, в отсутствие UI отвлекаться больше не на что, и дебаггинг становится удивительно сфокусированным действом.

С тех пор как у .NET Framework появился кросс-платформенный брат близнец .NET Core, я всё выжидал, как бы это повторить давнишний подвиг ещё раз, но уже для C#, и недавно это-таки случилось. Не совсем гладко, но тем не менее. Давайте смотреть.

Читать далее Дебаггинг .NET Core приложения из командной строки в Linux

Тайна «Debug adapter process has terminated unexpectedly»

vs code

Любопытная история приключилась со мной намедни. Моя основная C# IDE на никсовых системах — Visual Studio Code — внезапно приказала долго жить. Не целиком, а самая полезная её часть — дебаггер. Стоило мне поставить брейкпоинт где-нибудь в коде и запустить проект, как редактор останавливал праздник интеллекта с ошибкой «Debug adapter process has terminated unexpectedly»:

Debug adapter process has terminated unexpectedly

A вот раньше всё работало просто прекрасно. Так как незадолго до проблемы я устанавливал на Убунту сразу несколько новых связанных с дебаггингом утилит (lldbperf и lttng), то естественно подумал, что проблема пришла от них. Но ни их удаление, ни переустановка VS Code целиком не изменили ровным счётом ничего.

В довесок к этому единственная внятная альтернатива VS Code для работы с C# на Linux — JetBrains Rider — тоже косячит. Какие-то проекты она может запустить и дебаггить, какие-то — нет. Те, что мне нужны, например, она даже запустить не может. В общем, не оставалось ничего другого кроме как начать разбираться, кто убил VS Code. Читать далее Тайна «Debug adapter process has terminated unexpectedly»

Отправляем .NET Core метрики в Graphite через StatsD

.NET Core StatsD

Уже прошло больше года с тех пор, как я подключил кусок JavaScript к collectd плагину и начал собирать данные мониторинга с нашей CI, чтобы потом хранить их в Graphite. И знаете что? Оно до сих пор работает. Даже JavaScript’овая часть. Но настали времена, когда мне нужно будет собирать метрики с .NET Core сервисов, и, чувствую, связкой JavaScript + collectd я уже не отделаюсь.

По идее, проблем быть не должно. В Graphite ведь можно отправлять данные хоть по TCP в виде текста, так что сервисы вполне могут заняться этим самостоятельно. Но можно сделать даже ещё проще. Читать далее Отправляем .NET Core метрики в Graphite через StatsD

Профайлинг .NET Core приложения в Linux

flamegraphА тем временем я продолжаю разбираться в том, как дебагить .NET Core приложения в Linux. Теперь я уже более или менее представляю, как анализировать проблемы с памятью, но таких на самом деле у нас не так уж и много. Самая распространённая проблема — загрузка процессора под 100%, и тогда очень, очень хочется понять, чем же это приложение таким занимается.

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

Логи и трейсы, разумеется, существуют и на Linux, но мне было интересно, можно ли на нём профайлить .NET Core примерно так же, как и на Windows. Как оказалось, инструментов почти куча, но применительно к .NET Core основными выглядят три: утилиты perf, lttng  и perfcollect. Вот на них мы сейчас и посмотрим. Читать далее Профайлинг .NET Core приложения в Linux

Дебаггинг памяти .NET Core приложения в Linux

Дебаггинг памяти .NET Core приложения в Linux

Большую часть прошлой недели мне пришлось экспериментировать с виндовым .NET проектом под Linux и в Kubernetes. Это на самом деле не такая уж и дурка, как кажется поначалу. Проект мы заранее перевели на кросс-платформенный .NET Core, я отловил практически все проблемы, которые вплыли в никсе под контейнерами, и по итогу в K8s проект действительно заработал. Почти.

На практике всё равно остались мелкие неприятности. Эпизодически выскакивали всякие StackOverflow (хорошо хоть не segmentation faults), да и мой дебагерский виндовый опыт оказался практически бесполезным на никсах.

Например, практически сразу мы заметили, что, запускаясь под контейнером, проект с ходу отъедал 300 мегабайт физической памяти и около 2-х гигов виртуальной. В виндовом продакшене, конечно, под нагрузкой бывало и на порядки больше, но вот тут, на Linux, в демо-режиме, это много, мало, или вообще как? Как это проверить в принципе? На Винде я бы сделал дамп процесса, запустил Visual Studio или WinDBG и гуглил, что теперь делать дальше. А что тут?

Как выяснилось, гугл под Linux тоже работает, так что через пару часов медитации на монитор я выучил несколько интересных штук, о которых и хотел бы рассказать сегодня. Читать далее Дебаггинг памяти .NET Core приложения в Linux