Системное программирование *

Мне по работе часто приходится сталкиваться с высоконагруженными многопоточными или многопроцессными сервисами (application-, web-, index-server).
Достаточно интересная, но иногда неблагодарная работа — оптимизировать все это хозяйство.
Растущие потребности клиентов часто упираются в невозможность просто заменить железную составляющую системы на более современную, т.к. производительность компьютеров, скорость чтения-записи жестких дисков и сети растут много медленнее запросов клиентов.
Редко помогает увеличение количества нодов кластера (система как правило распределенная).
Чаще приходится запустив профайлер, искать узкие места, лезть в source code и править ляпы, которые оставили коллеги, а иногда и сам, чего греха таить, много лет назад.
Некоторые из проблем, связаных с синхронизацией, я попытаюсь изложить здесь. Это не будет вводный курс по многопоточному программированию — предпологается, что читатель знаком с понятием thread и context switch, и знает для чего нужны mutex, semaphore и т.д.

За счет чего же мы наблюдаем постоянный рост производительности однопоточных программ? В данный момент мы находимся на той ступени развития микропроцессорных технологий, когда прирост скорости работы однопоточных приложений зависит только от памяти. Количество ядер растет, но частота зафиксировалась в пределах 4 ГГц и не дает прироста производительности.

Скорость и частота работы памяти — это то основное за счет чего мы получаем «свой кусок бесплатного торта» (ссылка). Именно поэтому важно использовать память, настолько эффективно, насколько мы можем это делать, а тем более такую быструю как кэш. Для оптимизации программы под конкретный компьютер, полезно знать характеристики кэш-памяти процессора: количество уровней, размер, длину строки. Особенно это важно в высокопроизводительном коде — ядра систем, математические библиотеки.

Как же определить характеристики кэша автоматический? (естественно cpuinfo распарсить не считается, хотя-бы потому-что в конечном итоге мы бы хотели получить алгоритм, который можно без труда реализовать в других ОС. Удобно, не правда ли? ) Именно этим мы сейчас и займемся.

Немного теории

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

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

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

Когда участвуешь в разработке достаточно сложных проектов, то написать неправильно работающий код проще простого. Вся загвоздка заключается в том, что ошибку начинаешь искать в самых темных закоулках проекта, в самых сложных его частях. При этом в голову даже и мысли не приходит, что не работать может самый простой код, основа всего проекта: framework.
В данном посте я опишу две проблемы, с которыми я столкнулся на практике: невозможность создать еще один поток и переименовать файл. Используемый язык программирования: C/C++.

Как известно, жесткие диски — штука шаткая. Особенно верно это в малом пользовательском классе, в котором и не мечтают о надежности, скажем, серверного оборудования. Однако отказы милых нашему сердцу железок в самый неподходящий для этого момент могут даже домашнему пользователю доставить очень много неприятных минут, часов или даже дней (об одном таком случае я недавно рассказывал, в резюмирующих строках статьи, к сожалении, не выразить, сколько времени было убито на борьбу с неверным оборудованием). Столкнувшись с задачей максимально быстро выяснить, в какой участок едва живого внешнего жесткого диска емкостью 160 Гб. воткнуть раздел размером хотя бы 10 и быть в нем более-менее уверенным, я с удивлением обнаружил, что, по крайней мере оставаясь верным операционным системам семейства Linux, сделать это существующими средствами не получится. Как пришлось выкручиваться — добро пожаловать под кат.

CRIU (application Checkpoint/Restore In Userspace) — это амбициозный, быстро развивающийся проект, который позволяет сохранить состояние программы в виде контрольной точки, и впоследствии возобновить работу приложения с этой точки.
Возможности применения программного обеспечения для создания контрольных точек достаточно разнообразны. К примеру, OpenVZ использует похожий механизм для “живой” миграции. Parallels Virtuozzo использует подобный механизм для быстрого возобновления работы контейнеров после обновления ядра. CRIU уже используется в высокопроизводительных кластерах для для сохранения промежуточных результатов вычислительных процессов, используемых для возобновления работы приложения в случае сбоя.
В этой статье рассказывается, как CRIU сохраняет и восстанавливает состояние программы, и почему этот проект может быть успешнее своих предшественников.

Так уж случилось, что я выбрал профессию системного администратора. И занимаюсь этим порою неблагодарным делом уже без малого около 6 лет.
Однажды, пару лет назад, передо мною встал вопрос, позже переросший в задачу, заключающийся в том, как же относительно быстро завести новые учётные записи пользователей в AD под MS Windows Server 2003?

Я понимаю, конечно, что Сколково, гос-корпорации, непонятное название, много псевдонаучного PR по поводу этих самых клеток и прочие негативные коннотации имеют место быть, но партия процессоров изготовлена. Их даже можно потрогать руками и посетовать на кривые ножки :) в новости на картинке не фотошоп — на сайте разработчиков и в прокремлёвской газете (не, ну мне самому стыдно, однако… против факта не попрёшь).

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

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

В период с 16 июля по 10 августа в Москве мы проводим Летнюю школу системного программирования. В рамках Летней школы все желающие смогут прослушать курсы лекций по архитектуре операционных систем, информационной безопасности и криптографии, а так же принять участие в реальных проектах по разработке операционных систем.

Пятая лекция курса «Сетевое программирование в UNIX» от специалистов SkyDNS и компании «Айдеко» уже ждет своих слушателей.

Александр Патраков объясняет, как перевести обычную сетевую программу в программу, основанную на конечном автомате.

О том, что такое конечный автомат, вы узнаете под хабракатом.

Я снова вернулся к любимой задаче для освоения новых языков. После написания движка для блога на Go, захотелось снова поразмять пальцы, болезный TCP/IP proxy/debugger теперь написан на Go.

Вкратце, TCP/IP proxy — это программа, которая умеет принимать соединения и «пробрасывать» их на указанный адрес. Попутно ведутся логи переданных данных. Это очень удобно при отладке различных самодельных сетевых протоколов.

В плане функциональности версия на Go, как и эрланговская, ведет три лога: двунаправленный шестнадцатеричный дамп и бинарные логи в обоих направлениях, «от» и «к» удаленному хосту. Питоновская версия бинарные логи не ведет.

Конечно, все многопоточно. И так как в Go параллельное программирование настолько просто (и безопасно), количество параллельных активностей для каждого соединения даже больше, чем в версии на Эрланге.

Он посинел, ему плохо?

BSOD – реакция ядра на неразрешимую исключительную ситуацию. Если вы его видите, то это значит, что случилось что-то определенно нехорошее.

Среда ядра накладывает множество ограничений на свободу действий программиста: учитывай IRQL, синхронизируй доступ к разделяемым переменным, не задерживайся в ISR, проверяй любые данные из «юзерленда»… Нарушив хотя бы одно из правил, вы получите настоящий выговор из штампованных фраз в стандартном VGA-видеорежиме с худой палитрой.

Недавно с рассылкой от компании Redgate (это та компания, которая выпустила всем известные тулы .Net Reflector, SmartAssembly и прочие) получил бесплатную книгу «Under the Hood of .NET Memory Management». Пока что доступна только первая ее часть, но она довольно объемная и раскрывает многие аспекты менеджмента памяти. Самое вкусное обещают во второй части. Приятного скачивания (краткое содержание под катом):

• Ссылка на официальную страницу с подпиской на выход второй части
• Прямая ссылка на pdf:
  Under the Hood of .NET Memory Management (Part 1)

Бонусом по первой ссылке, в том же архиве, идет книга по ANTS Memory Profiler

Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.

Почта в своей конторе разрослась и наличие более чем 1 рабочего места у более чем 1 сотрудника начали требовать большего, нежели простейшая реализация мультидоменного почтового сервера на базе exim+teapop без использования mysql на обычных файликах. Главная причина изменений — постоянное вычищение спама и просто ненужных писем на каждом из рабочих мест по многу раз начало доставать, и было принято решение реализовать-таки почту по известной статье лиссяры "Связка exim и courier-imap". Самое главное, чего в ней не хватало из того, что требовалось, так это сортировщика писем по папкам. Для того, кто подписан на рассылки, весьма полезно раскладывать письма по требуемым каталогам, чтобы: а) не писать сортировщики в каждом клиенте; б) иметь такую же структуру папок при доступе к почте через веб, как и в почтовом клиенте.

О прекрасной библиотеке Microsoft Detours тут уже писали. Её возможности и правда впечатляют, есть только одно но: библиотеку нужно собирать из исходников (что вообще не характерно для библиотек на платформе Windows и тем более для продуктов Microsoft). Более того, внятную инструкцию как это сделать найти трудно (я так и не смог), а штатный make-файл при сборке с помощью Visual Studio 2008 выдаёт кучу ошибок. Собрав наконец Detours, я решил написать (для себя — на будущее) инструкцию по сборке. Если кому-то она сэкономит пару минут — буду рад.

В продолжение темы расширения функциональности готовых программ хотелось бы рассказать об ещё одном способе изменения логики работы уже скомпилированной программы, который не требует делать изменений в самом исполняемом файле. Это может пригодиться при распространении вашей модификации в США, где прямое вмешательство в исполняемый файл строго осуждается. Речь пойдёт о создании крошечной прокси-dll (всего ≈4 килобайта) для подмены используемой приложением библиотеки на примере ddraw.dll.

Тема отображения текущей раскладки беспокоила хабрасообщество уже не раз. Я опробовал множество существующих решений, но по разным причинам они меня не устроили. Чтобы подобрать для себя наиболее удобный вариант отображения текущей раскладки, я написал небольшое приложение на C++, которое при нажатии на левый Shift отображает язык в системном курсоре редактирования текста. Менее 100 строк кода и около 4 килобайт в скомпилированном виде — на основе этого вы можете достаточно просто реализовать свой взгляд на то, как на самом деле должна выглядеть индикация текущей раскладки.