Всем привет! Я руковожу командой антиспама в Mail.ru Group, а также несколькими группами по машинному обучению. Тема этой статьи — саморазвитие для тимлидов/руководителей, но на самом деле многие техники и рецепты совершенно не зависят от роли. Для меня этот вопрос очень актуален, так как машинное обучение развивается крайне стремительно, и чтобы хотя бы быть в теме, надо потратить уйму времени. Поэтому вопрос, как и на что тратить время для развития, стоит достаточно остро.

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

В одном из чатов мне задали вопрос:

— А есть что-то почитать, как правильно упаковывать сервера в стойки?

Я понял, что такого текста не знаю, поэтому написал свой.

Во-первых, этот текст про физические сервера в физических дата центрах (ДЦ). Во-вторых, считаем, что серверов достаточно много: сотни-тысячи, для меньшего количества этот текст не имеет смысла. В-третьих, считаем, что у нас есть три ограничителя: физическое место в стойках, электропитание на стойку, и пусть стойки стоят в рядах, так что мы можем использовать один ToR свитч для подключения серверов в соседних стойках.

Основанный в 2006 году BlaBlaCar считается крупнейшим в мире онлайн-сервисом поиска автомобильных попутчиков (ridesharing). Появившись во Франции, сервис прошёл активную экспансию в Европе, с 2014 года стал доступен в России и Украине, а позже добрался до стран Латинской Америки и Азии. Рост популярности онлайн-сервисов неизбежно связан с развитием стоящей за ними ИТ-инфраструктуры, и, как легко догадаться из названия статьи, сегодняшние потребности BlaBlaCar реализуются благодаря Kubernetes. К чему же пришли ИТ-инженеры компании?

Друзья, мы рады сообщить, что перевод всего гарвардского курса CS50 закончен.

Мы писали, что в курсе 24 серии, однако последние две оказались одной и той же лекцией (одна прочитана в Гарварде, а другая в Йеле), поэтому в списке переведённых лекций не 24, а 23.

Список лекций под катом.


Курс переведён и озвучен нашей студией по заказу JavaRush, и мы хотим сказать им огромное спасибо за поддержку!

Не секрет, что Net-Tools пора на почетную отставку. Да, многим админам и мне в том числе, до условного рефлекса Павлова знакомы команды ifconfig, route, netstat. На первый взгляд нет причин что-то менять, а лучшее как всегда враг хорошего.

Давайте узнаем почему Net-Tools уже не тот и как безболезненно с него перейти на iproute2 .

В данной статье я хочу показать насколько просто сегодня использовать нейронные сети. Вокруг меня довольно много людей одержимы идеей того, что нейронки может использовать только исследователь. И что бы получить хоть какой то выхлоп, нужно иметь как минимуму кандидатскую степень. А давайте на реальном примере посмотрим как оно на самом деле, взять и с нуля за один вечер обучить chatbot. Да еще не просто абы чем а самым что нинаесть ламповым TensorFlow. При этом я постарался описать все настолько просто, что-бы он был понятен даже начинающему программисту! В путь!

Перед любым системным администратором рано или поздно возникает задача количественного анализа трафика (откуда / куда, по каким протоколам / портам, в каких объемах и т. п.), проходящего по его сети. Особенно неприятно, когда эта задача возникает спонтанно, как побочный результат DDoS-а, а денег на серьезные решения от Cisco или Arbor, как обычно, нет. И хорошо еще, если шлюзом для сети выступает сервер, на котором можно запустить tcpdump или wireshark, но что делать если:

• шлюзом выступает устройство провайдера, а в сети есть только файл-сервер;
• данные о трафике нужны не постоянно, а от времени к времени;
• устройство не поддерживает возможность запуска на нем сторонних программ;
• трафика столько, что сервер после запуска tcpdump-а «клеит ласты»;
• или наоборот, настолько мало, что его уровень сравним с долей (хотя и значительной) обычного трафика?

В мануале есть всё. Но чтобы его целиком прочитать и осознать, можно потратить годы. Поэтому один из самых эффективных методов обучения новым возможностям Postgres — это посмотреть, как делают коллеги. На конкретных примерах. Эта статья может быть интересна тем, кто хочет глубже использовать возможности postgres или рассматривает переход на эту СУБД.

Последняя статья про классические примитивы синхронизации.

(Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

Сегодня мы немножко заглянем в процессор. Чуть-чуть.

По сути, мы будем говорить про единственный примитив, который принципиально отличается от остальных: спинлок. Spinlock.

В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

Есть и ещё одно, семантическое различие. Мьютекс допускает и предполагает снятие нити с процессора, долгую остановку вызывающей нити. Мьютексом можно запереть объект на час или сутки, это приемлемо и нормально. Спинлок принципиально рассчитан только на кратчайшие приостановки, это всегда работа с неатомарным стейтом объекта. Присваивание группы переменных, небольшой цикл — это максимум того, что можно сделать под спинлоком.

Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

Как устроен спинлок?

Много лет назад друг принес мне поиграть одну игрушку для тех, кто учится программировать. Уже тогда я достаточно хорошо программировал, и подумал, что игра не для меня, но решил попробовать.

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

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

1. Предисловие

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

Системные администраторы имеют большое количество скриптов для автоматизации. Хранятся они, обычно, в их домашних папках (и хорошо если не только там, но и в CVS), периодически апдейтятся на новую функциональность. Как правило, использовать такие скрипты могут лишь те же люди которые их пишут (а, иначе, последствия могут быть самыми разрушительными).

Таким образом — задачи по автоматизации часто нуждаются в простом GUI для удобного управления, упрощения. Например — сбор трафика. Или возможность откатывать бекапы/релизы по кнопке (даже если кто-то катится пакетами через SCM систему). Или менять Mysql master без подглядывания консоль ( какое-то количество ошибок возникает из-за неверно забитой в команды, не на том сервере).

«Moving from the one-room schoolhouse to the one-world schoolhouse is now a reality» (Cisco Systems)

«One-room schoolhouse» — это американская сельская школа времен Марка Твена; в такой учился ещё Том Сойер — формат обучения, который до сих пор знаком каждому, кто ходил на какие-либо курсы, включая обучение английскому. Не слишком-то прогрессивно для мира облачных сервисов и глобальных видеоконференций?


Мы учились английскому у этого парня

Речь в статье пойдет о роутинге сетевых пакетов в Linux. А конкретно – о типе роутинга под названием policy-routing (роутинг на основании политик). Этот тип роутинга позволяет маршрутизировать пакеты на основании ряда достаточно гибких правил, в отличие от классического механизма маршрутизации destination-routing (роутинг на основании адреса назначения). Policy-routing применяется в случае наличия нескольких сетевых интерфейсов и необходимости отправлять определенные пакеты на определенный интерфейс, причем пакеты определяются не по адресу назначения или не только по адресу назначения. Например, policy-routing может использоваться для: балансировки трафика между несколькими внешними каналами (аплинками), обеспечения доступа к серверу в случае нескольких аплинков, при необходимости отправлять пакеты с разных внутренних адресов через разные внешние интерфейсы, даже для отправки пакетов на разные TCP-порты через разные интерфейсы и т.д.
Для управления сетевыми интерфейсами, маршрутизацией и шейпированием в Linux служит пакет утилит iproute2.

Предисловие

Пост является кратким конспектом Wiki, TechNet'а, FreeBSD'шного handbook'a, Serverfault'a, множества RFC и документов IANA, а также курсов от Специалист.Ру для сотрудников Яндекса.

Пост можно рассматривать как копилку ссылок по актуальной на 2012 год спецификации IPv6. Однако он никак не описывает возможные способы установки IPv6 соединения с интернетом и не привязан к какой-либо определённой ОС.
Учтите, что прочтение данной хабрастатьи займёт у вас не более получаса, однако крайне рекомендуется ознакомиться со всеми приведёнными в статье ссылками… Последнее может занять несколько недель.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.

Корпорация IBM работает совместно с DARPA над созданием нейроморфных чипов (Systems of Neuromorphic Adaptive Plastic Scalable Electronics, SyNAPSE) уже много лет, реализация проекта началась еще в 2008 году. Цель — создание чипов и систем, работа которых была бы организована по принципу работы нейронов мозга животных (например, грызунов). Это очень сложная задача, и специалистам пришлось потратить на ее решение немало времени. Сейчас, наконец, представлены первые значительные результаты проекта SyNAPSE.

Система TrueNorth, состоит из отдельных чипов-модулей, которые работают, как нейроны мозга. Соединяя нейроморфные чипы в систему, исследователи получают искусственную нейронную сеть. Версия, которую представила IBM, включает 48 млн соединений — это близко к числу синапсов в мозге крысы. Представленная структура состоит из 48 отдельных чипов-модулей.

Управление памятью – одна из главных задач ОС. Она критична как для программирования, так и для системного администрирования. Я постараюсь объяснить, как ОС работает с памятью. Концепции будут общего характера, а примеры я возьму из Linux и Windows на 32-bit x86. Сначала я опишу, как программы располагаются в памяти.

Каждый процесс в многозадачной ОС работает в своей «песочнице» в памяти. Это виртуальное адресное пространство, которое в 32-битном режиме представляет собою 4Гб блок адресов. Эти виртуальные адреса ставятся в соответствие (mapping) физической памяти таблицами страниц, которые поддерживает ядро ОС. У каждого процесса есть свой набор таблиц. Но если мы начинаем использовать виртуальную адресацию, приходится использовать её для всех программ, работающих на компьютере – включая и само ядро. Поэтому часть пространства виртуальных адресов необходимо резервировать под ядро.



Это не значит, что ядро использует так много физической памяти – просто у него в распоряжении находится часть адресного пространства, которое можно поставить в соответствие необходимому количеству физической памяти. Пространство памяти для ядра отмечено в таблицах страниц как эксклюзивно используемое привилегированным кодом, поэтому если какая-то программа пытается получить в него доступ, случается page fault. В Linux пространство памяти для ядра присутствует постоянно, и ставит в соответствие одну и ту же часть физической памяти у всех процессов. Код ядра и данные всегда имеют адреса, и готовы обрабатывать прерывания и системные вызовы в любой момент. Для пользовательских программ, напротив, соответствие виртуальных адресов реальной памяти меняется, когда происходит переключение процессов:

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

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

Ниже — достаточно известные вещи, которые, однако, вызывали facepalm у тех, кто был вместе со мной или же у меня. В списке грабель вы с некоторой вероятностью можете найти что-нибудь новое. Если хотя бы она фича использования вспышки окажется для вас полезной, то мою задачу можно считать выполненной.