Деградация Windows Server

Есть у меня простенький компьютер. Был куплен в порыве шопоголизма на распродаже. Я так и не придумал, чем занять данный компьютер, поэтому накатил на него Windows Server 2016 (По факту LTSB сборка 10-ой винды 1607, которая Anniversary Update, но с серверными фичами). Компьютер после запуска (и ожидания 8 минут, пока винда разберётся со своими внутренними делами) выглядел так:

Если не вдаваться в подробности, то запущено 54 процесса, 848 потоков и занято 0.9Гб оперативки. Вполне допустимая ситуация для пустого сервера, хотя всегда хочется меньше.

Но я решил потестировать недавно вышедший Windows Server 2019, эта та же Windows 10, только уже злополучная 1809, October 2018 Update. Я просто обновил сервер, подождал джентльменские 8 минут и результат на экране:

Процессов уже стало 110 (ровно в два раза больше!), количество потоков увеличилось всего на 300 штук, что уже лучше, хендлов стало больше почти в 2 раза и сожрано стало на 400МБ оперативной памяти больше.

Ещё раз, для понимания бреда. За 2 года разработки операционная система на свои личные нужды стала использовать гораздо больше ресурсов. Может от этого она стала быстрее или лучше работать? Как-то незаметно. Вместо оптимизации системы в итоге получаешь просто ещё больше внутреннего потребления. Зачем? А просто так, потому что программисты Microsoft могут тратить ресурсы как захотят. Железо же становится быстрее, памяти больше, никто и не заметит. И вот это бесит неимоверно.

UPD: Оказывается, это сознательное решение Microsoft, они в 1703 разгруппировали сервисы, если в системе больше чем 3.5ГБ памяти. Объяснили как всегда надёжностью и безопасностью. Но памяти это, конечно же, жрёт больше, о чём не скрывают. А то, что "стабильность" теперь зависит от количества оперативной памяти — выглядит это очень странно.

UPD2: Поиск решения проблемы привёл на следующую ссылку, надо в реестре по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control отредактировать (создать?) ключ SvcHostSplitThresholdInKB, изменив там количество памяти для разделения процессов. Итог изменения ключа следующий:

Процессов и памяти резко уменьшилось. До старых значений ещё не доходит, но всё-таки результат стал получше. 

Yappi Days 2018. Впечатления

Изначально не планировал идти на эту конференцию, но привлекли пара докладов и свободная суббота, так что решил сходить.

В результате понял, что местные конференции, организованные местными компаниями весьма и весьма унылы. Впрочем, с организацией всё было хорошо, как у взрослых, тут придраться не к чему, проблема с докладами...

Изначально у конфы не заявлена специализация, просто конференция для разработчиков (видно, чтобы собрать всех желающих программистов Ярославля, кстати, их удивительно много, и занимаются интересными вещами, удивился). В результате, темы были весьма разными (чтобы всем хватило), а сложность докладов очень низкая, местами очень капитанская.

При этом, доклады от спонсоров очень хорошо выделялись своей очевидностью и рекламой. Например, доклад про PVS-Studio был всего-лишь рекламой PVS-Studio (продукт, кстати, хорош, и на стенде очень плодотворно пообщались с разработчиками), доклад от Тензора поразил своим абсолютным, нереальным отсутствием практического смысла (рекламировалась внутренняя утилита компании Тензор, т.е. её не увидеть, не пощупать, и использовать можно только если ты работаешь в Тензоре).

Также, у организаторов вышла лажа с порядком докладов: вначале Владимир Ильмов рассказывал про Netflix стек для микросервисов и докер у него был как базовая концепция, а затем был доклад про то, что такое докер в принципе. Совсем не понял, в чём был смысл доклада от CUSTIS, назывался он "Как работает браузер", в реальности человек начал рассказывать про то, что такое DNS, как в http передаются заголовки. Т.е. такой вымученный доклад, лишь бы что-то рассказать (да, я даже в лекции для студентов старался держать уровень выше). При этом CUSTIS никак себя не рекламировал (не было стендов), и смысл им рассказать один бестолковый доклад — я так и не понял.

Конечно, т.к. было 3 потока, я не мог посетить все доклады, возможно, я пропустил что-то интересное, но общее впечатление весьма посредственное. Причём именно из-за докладов — слишком обще, слишком просто, слишком про всё. Надо специализироваться и повышать уровень. И ещё раз скажу, с организацией всё было отлично, а халявные пиццы от Пиццы-Фабрики очень рулили.

Да, и жестокий и беспощадный хантинг преследовал всю конференцию, слей контакты и поучаствуй в розыгрыше, заполни анкету и получи банку Колы, иди, сука, в Тензор! В общем, жду вторника, буду смотреть на результат сего действия (я же не сноб, и отдал свои контактные данные, чего жадничать-то).   

WireGuard

Сегодня Роскомнадзор в очередной раз забанил подсеть Амазона (или хостер пофиксил "проблему"), в общем пришлось заворачивать всё в VPN, что привело к весьма печальной скорости работы сервера, т.к. VPN был далеко.

Решил поднять его поближе, в Azure, а т.к. в нём весьма грустно с фаирволлом, решил попробовать новый хипстерский VPN под названием WireGuard. Правда потом оказалось, что VPN всё-таки можно было попробовать устроить, но у меня оказалась неправильная виртуалка, в которой всё делается через жопу. Надо было создавать другую и гуглить как в азуровом фаирволле сделать проброс чего-то отличного от TCP и UDP.

В общем, WireGuard позиционируется как простой и правильный VPN, без кучи опций и настроек. Просто работает. И в целом да, только оказалось, что это нифига не VPN в привычном понимании (хотя технически да, и виртуальная, и частная, и сеть).

Что хочется получить от VPN:

• Стабильной работы (у всех существующих решений всё плохо)
• Простой конфигурации (PPTP рулит)
• Безопасности (SSTP, L2TP/IPSec, OpenVPN)
• Выдачи IP адресов (все умеют)
• Выдачи маршрутов (у всех очень грустно)
• Выдачи доп. настроек (ещё хуже)

При этом, стоит напомнить про такую технологию как IPSec, которая не является туннелем сама по себе, т.е. не приносит дополнительных интерфейсов и IP-адресов, а просто безопасно заворачивает IP пакеты в себя. Т.е. идеально подходит для связи Server-Server или Сеть-Сеть через конкретные шлюзы. Для динамики и NAT подходит весьма плохо.

И вот тут вылезает WireGuard. Что же он делает?

• Создаёт отдельный сетевой интерфейс
• На него руками необходимо назначить IP (wat?)
• Клиент и сервер в целом не разделяются (привет IPSec), они равнозначные пиры (peers), но в целом можно использовать концепцию клиент-сервер, просто сделав определённые настройки
• Если нужно устроить VPN, то можно сделать это ручками через iptables и маскарад
• Каждый пир определяется парой ключей (публичным и приватным), так что заранее на сервере никого не добавить (можно нагенерить ключей, но как-то коряво выглядит)
• По умолчанию роуты связаны со списком разрешённых IP'шников, т.е. делаются на клиенте, проброса нет

Так что получается, что это какой-то упрощённый IPSec, но с отдельным интерфейсом и IP-адресом (без добавления, думаю можно извернуться, но уже не очень дефолтная конфигурация). Т.е. использовать его как VPN — можно, но очень фигово (хотя если для себя делаете, то вполне норм). И с VPN'ами по-прежнему всё тухло, а WireGuard оказался каким-то странным созданием.

Но с другой стороны, настраивается он элементарно и начинает сразу же работать. Это ему плюс. Только имейте в виду, что конфигурация через wg-quick и ip работает по-разному, через ip можно сделать гораздо больше и и точнее.

Хранение данных в памяти

Очень давно вынашиваю идею о том, что базу данных для приложения стоит размещать в памяти. Конечно, не полностью в памяти, основную базу оставить, но использовать очень и очень агрессивное кеширование. Зачем? Об этом ниже.

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

Почему не стоит полагаться на кеш SQL-сервера?

Потому что он построен именно на модели кеша для данных, и в него можно попадать или не попадать. Конечно, в MS SQL есть OLTP таблицы, которые хранятся в памяти, но они больше для очень активных данных, и вообще это на уровне SQL, причём MS SQL. А без них — используются стандартные алгоритмы для поиска, оптимизированные для данных, находящихся на диске, как результат, необходимый кеш для очень 100% попадания в память многократно превышает размер реальных данных.

Я же предлагаю забить на это, и максимально хранить все данные из базы в памяти (загружать их из базы на старте, или ленивым образом).

Что это даёт?

• Резко упрощается внешняя логика пользователя. Во многих случаях можно отказаться от джойнов, если нет дополнительной фильтрации. Например, классический джойн с данных с пользователем (например, вывести автора данных) можно заменить на выборку данных и доставание всех пользователей по ID. Это очёнь дешёво
• Можно использовать очень тупые алгоритмы, и это всё равно будет очень быстро. Фуллскан 10000 записей почти незаметная вещь, а если надо будет ещё быстрее — всегда можно будет прикрутить "индекс" в виде словарика
• Можно избавиться от отдельного кеша для тяжёлых данных, ибо и так всё в памяти
• Тупо быстрее из-за отсутствия запросов к внешнему SQL-серверу
• Легко хранить данные, которые тяжело забирать из SQL (объект с зависимыми детишками, слабо-структурированные документы, JSON/XML поля)
• При этом, если приложение написано с использованием LINQ, то местами можно вообще не заметить разницы между базой и памятью (если грамотно спланировать архитектуру приложения)

 А в память влезет?

А вот это как раз главный вопрос, который всех останавливает и которого все боятся. И из-за этого, всё так и останавливается на уровне идей. Но давайте прикинем необходимое количество памяти.

• База данных в 20ГБ содержит где-то 20ГБ данных (логично, да?), в памяти это будет занимать примерно столько же. Найти подходящий сервер — не так уж и сложно. Естественно, базы в 100МБ вообще влезут в память без проблем
• Очень часто в "больших" базах большой объём занимают всякие полумёртвые данные — журналы, результаты импорта, файлы, подписанные данные, акксесс логи... Эти данные нужны очень редко, их можно не хранить в памяти, тем самым кардинально снизив объём "реальных" данных
• Многие данные нужны только в небольшом количестве. Например, у вас есть 10000 пользователей в системе, но активны только 1000, тут можно использовать какой-нить LRU кеш и не держать в памяти все объекты, а только активные. Опять же, очень сокращает необходимый объём памяти
• Ну и для реально огромных баз данных можно уж держать в памяти только специально выделенные объекты (например, справочники). Хотя, с такими объёмами у вас будет проблем побольше чем просто держать в памяти

Как реализовать?

Поскольку я ещё не делал это в полном виде, то могу только предположить следующие варианты:

• Собственный кеш класса, ратающего с сущностью (e.g. UserManager), он сам решает, что и как кешировать. Проблемы в куче аналогичного кода в разных классах и сложность с инвалидацией. Плюсы: в каждом конкретном случае можно использовать самые эффективные варианты
• Мемоизация и автомемоизация методов. Плюсы: очень упрощается код, минусы: сложно инвалидировать и оптимально использовать данные. 
• Обёртка над ORM (или использование встроенных средств типа Second Level Cache), которая сделает всё сама. Проблемы: сложно в реализации и конфигурировании. Плюсы: полная прозрачность в использовании со стороны кода

Краткий итог

Данное агрессивное кеширование и разработка с учётом того, что оно есть, может кардинально поменять работу с данными в вашем приложении. Код будет проще, тупее и понятнее, но при этом весьма быстро работать, даже если выполняет сложные операции с данными.При этом сама база данных останется и в ней всегда можно покопаться, поделать аналитику, но при этом не сильно думать об её оптимизации (индексах, статистике и прочем тюнинге), это всё будет на уровне приложения, которое знает, что оно хочет от данных и как оно будет их использовать.

Итоги моего 2017 года

Решил в этом году повторить пост относительно прошлого, ибо оказалось даже для меня полезным и интересным посмотреть, что было в прошлом и сравнить, что стало (хотя уже было) в этом. Так что, нашёл время (единственный свободный день под конец года оказался, хотя сейчас пытаюсь восстановить угробленные виндой данные с диска в 3Тб), и решил написать, что же произошло технического в этом году.

Получилось так, что я почти забросил этот блог. ибо хочется писать про интересное, а это интересное надо долго и упорно изучать, чтобы пост не получился глупым и ошибочным. А в итоге получается, что занимаюсь или банальщиной, или не сильно углубляюсь, или лезу в такие дебри, что объяснить их не представляется возможным. А вот так, чтобы что-то интересное... На новый год принято давать себе обещания, типа бросить пить, заняться спортом, вести блог... Так вот не буду, ибо не знаю ещё, чем буду заниматься в следующем году...

А в этом активно и вплотную занялся .NET Core под Linux, фактически все новые проекты теперь там и живут, и живут весьма неплохо. На работе кроме всякой мелочи был сделан очень крутой проект. Он. конечно выглядит просто и банально, но внутри там очень всё круто, микросервисно, распредёлённо и кешированно. При этом, пока не замучали новыми фичами, он умудрялся жить на мелких виртуалках, используя по максимуму всё, что они предоставляли. Но в конце-концов, один проект превратился в два, с общей и своей частью, я сдался и развёл проект на 3 сервера и разрешил жрать память (хотя слишком разрешил 16 Гигов, съеденных из-за баги доставили много радости в поиске бага).

В остальном, год был похож на прошлый. Был хакатон, но участвовал я один, в итоге "почётное" третьё место. И ещё не внедрено. Продолжаю пилить на гитхабе свой клонятор, Crc32 (теперь ещё быстрее), и архиватор, который уже помаленьку использую в бою и вижу, что у него есть очень интересные фичи. Также нарисовал свой аналог IPSec под названием AutoTunnel, получилось интересно, но надо бы чуть допилить, ибо склейка фрагментированных UDP пакетов со стороны Windows — это боль.

С нетехнической стороны — год отметился путешествиями: Баку, Минск, Кострома, Мюнхен, Тбилиси, Амстердам, Прага... Посетил кучу мест, получил много впечатлений и не собираюсь останавливаться на достигнутом!

К сожалению, со всей этой беготнёй, забыл про новогоднее настроение, но у меня есть ещё 2 дня его найти, буду упорно стараться. Ну а вам его тоже желаю, надеюсь, что оно у вас уже есть и вы готовитесь к самому весёлому празднику, Новому Году.

С Наступающим!

Ненавистный .NET

Последнее время совсем не пишу в блог, как-то нет подходящих тем, могу только сообщить, что такой ненависти к Microsoft я давно не испытывал. Попытка поработать с .NET Core 2.0 сразу же привела к идиотским ошибкам, типа 2 entry point у приложения. При этом второй генерируется самостоятельно (!), другими словами, у Microsoft новые отличнейшие идеи, как всё должно работать по их мнению, вместо того, чтобы просто сделать рабочий продукт.

Если кончится мат и появятся слова, постараюсь написать что-то более членораздельное. Но, блин, у Microsoft был отличнейший .NET, приложения на котором просто работали... Теперь не так, они могут падать по совершенно различным причинам, а Dll Hell уже перешёл все границы. Ну, как, как можно так портить жизнь разработчикам за их же деньги...

Версионирование .NET Core

Когда-то писал про .NET Core и обещал написать больше, но было лениво, так что руки не дошли.

Сейчас просто для понимания бреда, который творится с версионированием краткое описание разных версий. Это может быть полезно, т.к. вышел .NET Core 2.0 и .NET Standard 2.0, и версии слились в экстазе. Но на самом деле они разные, и скоро разъедутся и будут опять портить всем жизнь. Итак, временно забудем про существование 2.0, и вспомним, что есть:

• Вы собрались писать под .NET Core, соответственно выбираете, какую версию хотите, вы можете выбрать версию 1.0 (на момент написания 1.0.7) или 1.1 (на момент написания 1.1.4), при этом, особой разницы в этом нет. 
• На самом деле, вы можете выбрать рантайм или сдк Логично, что для разработки нужен SDK, для версии рантайма 1.0.7, сдк имеет версию 1.1.4 (т.е. рантайм разрабатывается и старый и новый одновременно, сдк только новый)
• После этого, вы можете решить, что использовать, .NET Standard или .NET Core. Для библиотек лучше использовать Standard, у него версии: 1.0,1.1,1.2,1.3,1.4,1.5,1.6, для запускаемых файлов лучше Core, у него версии 1.0 и 1.1
• Впрочем, вы можете писать библиотеки на Core, а экзешники на Standard, в этом не очень много смысла, но в целом он есть
• Версии Standard для удобства используют стандартную библиотеку NETStandard.Library, она бывает версий 1.6.0 и 1.6.1
• В этой библиотеке есть стандартные библиотеки, которые любят называться как большие и иметь версию 4.3.0 (большие имеют версию 4.0.0). Впрочем, иногда бывают и 4.2.0 и 4.1.0, и всякие разные

Т.е. приложение мод .NET Core 1.0 может запускаться в рантайме 1.1.4, иметь зависимость на библиотеку .NET Standard 1.3, которая использует библиотеку NETStandard.Library 1.6.1 и это всё будет замечательно работать! Главное надо понять, что это просто разные версии разных библиотек. 

Сейчас вышел .NET Standard 2.0, и всё стало совсем просто: приложение под .NET Core 2.0 запускается в рантайме 2.0, имеет зависимость на библиотеку .NET Standard 2.0, которая использует библиотеку NETStandard.Library 2.0.0. К сожалению, скоро все эти версии опять разъедутся в разные стороны, и опять будет путаница. Но. надеюсь, вы теперь будете во все оружии.

PS: Сейчас слушаю про version hell в .NET Core 2.0, и становится страшно, там добавили совместимости из-за которой много всего развалилось, несмотря на обещанную совместимость.