stdray: (Default)
У нашей системы загрузки данных есть особенности: наличие жесткого дедлайна и единомоментное массовое появление данных на ключевых источниках. То есть в теории мы пытаемся получать информацию в реальном времени, а на практике выходит, что бОльшую часть суточного объема мы получаем в конкретные часы ночью и должны полностью отпроцессить к началу рабочего дня. Двигать делайн нельзя, потому что источники начинают выкладывать данные ночью по Москве, а во Владивостоке люди уже сидят и работают. Из-за чего можно видеть пики загрузки подсистем: сначала на получении первички, потом на трансформации, потом на раскладывании данных в детальный слой, на построении витрин и, наконец, индексации на полнотекстах.

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

По логам это выглядит так: интервал между двумя записями job'а, в который, грубо говоря, происходит лишь одна операция "создание из одного гигантского хэшсета другого с добавлением туда новых элементов", составлял чуть ли не 30 минут. Плюс в этот же период идут алерты, что на сервере кончилась память, потому что процесс всё пожрал. То есть, как я понимаю, процесс начал свопить и все замедлилось в зигалион раз.

Можно сходу набросать несколько вариантов, как эффективней работать:

  • не создавать новый хашсет, а мутировать старый

  • не работать с архивами в памяти, а распаковывать их в tmp

  • уменьшить фрагментацию памяти, используюя пул стримов

  • и так далее.



Другой вопрос, что перебирать варианты опасно и долго. И тут я понял, что плохо представляю себе как профилировать память приложения, которое жрет по 16+Гб на удаленном сервере. Варианты, которые я испробовал:

  1. JetBrains dotMemory через RemoteAgent. Не сработало, потому что долго конектится к процессу, долго делает дамп, НЕВЕРОЯТНО долго качает этот дамп, еще дольше его процессит. В итоге ни один дамп таким образом у меня открыт не был.

  2. Делаешь дамп штатными средствами ОС, качаешь Far'ом, открываешь в WinDbg и через sos смотришь !dumpheap -stat. Работает, но опять же долго делать дамп и очень долго качать.

  3. Открываешь дамп в dotMemory. Эта возможность помечена как "beta", работает 100500 лет, плюс у меня дважды упала ОС из-за ентова. На третий раз всё открылось быстро, но информация была крайне странная. профайлинг ёба
    (В ЖЖ почему-то не отображается картинка, если что она есть)
    Первая попытка профилирования, когда у меня помер пека, остановила процесс, потому что с того момента он больше не делал ничего. А что за дамп загрузился после второго падения, я хз. Хотя фантазия успела разыграться, несмотря на полное несоотвествие даже абсолютных значений реальной картине.

  4. Вспомнил, что видел у Саши Голдштейна какую-то утилиту на этот счет. Она не работает. Совсем. По крайней мере, у меня.

  5. Вспомнил, что есть clrmd и написал маленькую тулу вот такого вида. Она работает около минуты, дает более-менее похожие на правду значения. Вот ей пока и пользуюсь, только модифицировал, чтобы можно еще режим задавать (не только NonInvasive, но и Passive выбрать) и поставил в планировщик писать енти "логи" каждые 15 минут. Завтра буду разбирать.



Как вообще нормально профилировать память в серверных .Net приложениях? Поделитесь опытом. А то вот это всё дикое время на создение дампа, на перекатывание его туда-сюда просто убивает. Это как смотреть на растущее дерево. Должны же быть какие-то нормальные способы.
stdray: (Default)
Как писали в твитторе, в интересные времена живем:
- Microsoft без лишней скромности вкатился в Linux Foundation
- Заманил Google в .NET Foundation, который запиливает подержку дотнета для своего облака
- Показал Visual Studio для маководов. Студия уже приветствует неофитов
- Выложил для проб SQL Server, который v.Next, который можно пускать на линунксах
- Бомпанул Слек
- Сообщил, что Samsung отвлекся от производства взрывчатки, и опубликовал .NET SDK для Tizen
- Обратил внимание на проекты сообщества, такие как BenchmarkDotNet и NancyFX, приняв их в .NET Foundation
- Довел ASP.NET Core до такого состояния, что мы можем увидеть дотнет во всем известном некорректном бенчмарке


MS, правда, как я понял, прикончил WinPhone. Зато запустил совершенно непонятную мне ёбу. С другой стороны, пишут, что всё правильно MS делает




Сможешь ли ты совладать с ним?
stdray: (Default)
Решил посмотреть, чем ребята из соседнего комьюнити F# в плане unit-тестов промышляют. И нашел вот такой шаблон проекта. Скачал, установил, стал смотреть, чего там в файле проекта такого особенного. А ничего! То есть вообще самый обычный проект библиотеки классов!

Ну ок, качаю сборку Nemerle для 2012 студии. Это кстати оказалось труднее, чем я думал. Самое новьё сейчас доступно по ссылке http://tc.rsdn.ru/, там надо выбрать интересующую платформу и версию студии, потом выбрать последний удачный билд и на вкладке Artifacts уже можно забрать желанный msi. Я какбэ с TeamCity никогда не сталкивался, потому достаточно долго разбирался что и где.

Ладно, поставил Nemerle и интеграцию с 2012 студией. Создал проект библиотеки, добавил в зависимости уже поднадоевшую VisualStudio.QualityTools.UnitTestFramework.dll, написал два теста, собрал и... ВСЕ ТЕСТЫ ПОЯВИЛИСЬ САМИ. И даже отладка доступна и вообще все робит из коробки. То есть, я там вытанцовываю с бубном вокруг студии в стиле прыщавого админа, а прогресс рядом. MS, видать, переработали систему, избавившись от тех невменяемых ограничений и теперь все хорошо.

Правда, сама интеграция Nemerle с 2012 студий пока нестабильна, хотя большую часть времени работает весьма сносно. И я как-то побаивался переходить, но, думаю, безгеморройные тесты являются весомым аргументом.
stdray: (Default)
Написал про вуду-тесты для Nemerle в студии и уже хотел смотреть зомбоящик, как внезапно в голову пришла мысль, что возможно студия фильтрует проекты с тестами банально по расширению файла проекта. А ради совместимости с сишарповским тулзами Nemerle умеет компилировать достаточно большое подмножество C# и, соответственно, работать с проектами csproj.

Отлично, как и в прошлый раз создаю немерлевую библиотеку, добавляю Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll, пишу тесты. Компилирую - все собирается. Теперь удаляю проект из решения. Меняю ему расширение с .nproj на .csproj. Открываю файл проекта в текстовом редакторе и в самую первую секцию PropertyGroup копирую:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>


Пулучился .csproj следующего содержания: пример. Добавляю проект обратно в решение, компилирую и, вуаля, тесты доступны без всяких лишних проектов.

Отличия от предыдущего метода:
1) Там есть лишний проект, тут - нет
2) Там нельзя дебагером отлаживать тесты, тут - можно.
3) Там работал немерлевый автокомлит, тут - нет.

Я думаю, что так-то поудобней будет. Даже с учетом того, что автокомплит поломался. Но может и этот вопрос решаемый.
stdray: (Default)
Для написания unit-тестов я пользуюсь стандартными студийными возможностями - "Создать тестовый проект Visual C#" и пихаю туда тесты (суть классы и методы помеченные специальный атрибутами). Я не то чтобы фанат тестирования, просто писать тесты быстрее и проще, чем каким либо иным способом проверять написанную функциональность. И хотя я понимаю, что надо бы прочитать что-то про разработку через тестирование, про лучшие средства для него и тд, текущее положение дел меня вполне устраивает.

Однако, этот подход перестает работать, если пишешь код на чем-то отличном от C#/VB.NET/C++.NET, поскольку то ли в студию, то ли в mstest зашито данное ограничение. И хоть писать тесты на C# вполне приемлемо, это сильно раздражает. Как вообщем-то и ставить какие-то сторонние тулзы вроде NUnit большого желания нет, поскольку, во-первых, я уже привык к студийным возможностям вроде ведения списков тестов, ко всяким связанным с ними окошкам, а, во-вторых, предпочитаю по мере возможности пользоваться средствами из коробки.

Вообщем, мне надоело писать тесты к Nemerle на C# и я решил разобраться в проблеме. И хочу рассказать про вуду-решение, подходящее не только для Nemerle, но и для любых других языков .Net, не заапрувленных MS, вроде того же F#.

Первое, надо добавить в решение проект библиотеки на Nemerle (в моем случае это Nemerle.Mixins.Tests). К ней в зависимости добавить Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll, открыть соответствующее пространство имен и написать пару тестов. Что-то вроде такого:

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]

public class SimpleTest {

[TestMethod] public Fail() : void { Assert.IsTrue(1 == 2); }

[TestMethod] public Win() : void { Assert.IsTrue(1 == 1); }

}


Read more... )

August 2017

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930 31  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags