Аннотация

При помощи московского представительства компании IBM мы провели тестирование производительности последних версий СУБД PostgreSQL на серверах Power8, изучили масштабируемость зависимость производительности от количества одновременных запросов, нашли узкие места ограничивающие производительность, предложили новые технические решения и добились рекордной производительности.

Введение

В ряде задач практически неограниченного масштабирования по объему обрабатываемых транзакций можно достичь, используя распределённые системы, в которых тем или иным способом поток транзакций распределяется на большое количество серверов. Такое масштабирование часто называют “горизонтальным”. Однако, универсального распределенного решения не существует, кроме того, распределённость имеет свою цену. Архитектура системы должна заранее проектироваться как распределённая. Распределенные системы менее гибки, чем монолитные, к тому же они сложнее в эксплуатации и требуют более высокой квалификации персонала. Одни задачи легче поддаются распараллеливанию, другие — сложнее. Поэтому спрос на высокопроизводительные монолитные системы существует, и достижение возможно лучших результатов по производительности в рамках одного сервера было и остается важной задачей. Это часто называют “вертикальным масштабированием”.

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

Для решения таких проблем существуют механизмы управления доступом к ресурсам — использование блокировок, а также пригодные в некоторых случаях неблокирующие (lock-free) подходы. Рост производительности этих механизмов, а также детализация блокировок дает возможность снизить издержки, связанные с одновременным (конкурентным) доступом.

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

Этой статьей мы открываем серию публикаций, посвященных обнаружению ошибок и уязвимостей в open-source проектах с помощью статического анализатора кода AppChecker. В рамках этой серии будут рассмотрены наиболее часто встречающиеся дефекты в программном коде, которые могут привести к серьезным уязвимостям. Сегодня мы остановимся на дефекте типа «разыменование нулевого указателя».



Разыменование нулевого указателя (CWE-476) представляет собой дефект, когда программа обращается по некорректному указателю к какому-то участку памяти. Такое обращение ведет к неопределенному поведению программы, что приводит в большинстве случаев к аварийному завершению программы.

Занимаясь программированием рендеринга графики, мы живём в мире, в котором обязательны низкоуровневые оптимизации, чтобы добиться GPU-фреймов длиной 30 мс. Для этого мы используем различные методики и разработанные с нуля новые проходы рендеринга с повышенной производительностью (атрибуты геометрии, текстурный кеш, экспорт и так далее), GPR-сжатие, скрывание задержки (latency hiding), ROP…

В сфере повышения производительности CPU в своё время применялись разные трюки, и примечательно то, что сегодня они используются для современных видеокарт ради ускорения вычислений ALU (Низкоуровневая оптимизация для AMD GCN, Быстрый обратный квадратный корень в Quake).


Быстрый обратный квадратный корень в Quake

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

Эта статья — не исчерпывающее хардкорное руководство по железу. Это всего лишь введение, напоминание, свод базовых принципов написания эффективного кода для CPU. Я хочу «показать, что низкоуровневое мышление сегодня всё ещё полезно», даже если речь пойдёт о процессорах, которые я мог бы добавить.

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

Анатолий Орлов ( anatolix ), Денис Нагорнов ( Яндекс )

Анатолий Орлов: Всем привет! Меня зовут Анатолий. Я последние 10 лет работал в Яндексе. В Яндексе я занимался разными вещами, но, так получилось, что на HighLoad я всегда доклады делаю про скорость разного вида. У меня есть содокладчик — Денис Нагорнов, он и сейчас работает в Яндексе и занимается, помимо всего прочего, не поверите, тоже скоростью.

Доклад называется «Скорость с доставкой до пользователя». Как вы знаете, огромное количество компаний пытаются оптимизировать загрузку своих страничек. Некоторые компании так гордятся достигнутыми результатами, что они эти результаты пишут на своих страничках, причем даже не внизу, а вверху.

Например, скриншот с сайта Google:

Александр Крижановский ( krizhanovsky, NatSys Lab.)

По Сети уже давно бегает эта картинка, по крайней мере, я ее часто видел на Фейсбуке, и появилась идея рассказать про нее:

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

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

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

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

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

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

Прощай, год 2016-й. Здравствуй, год 2017-й.

Все мы знаем, что число 2017 простое (это же Гиктаймс, не так ли). Но оно гораздо больше, чем просто простое число.

Данный мануал/гайд/etc написан для тех, кому лень собирать по кускам ту или иную информацию об установке «мака» на PC, все понятно и по полочкам.

Вступление

В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.

Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:

Неповторяемое чтение — транзакция повторно читает те же данные, что и раньше, и обнаруживает, что они были изменены другой транзакцией (которая завершилась после первого чтения).

Фантомное чтение — транзакция повторно выполняет запрос, возвращающий набор строк для некоторого условия, и обнаруживает, что набор строк, удовлетворяющих условию, изменился из-за транзакции, завершившейся за это время.

Что же касается Serializable, то данный уровень изоляции самый строгий, и не имеет феноменов чтения данных.

Вечером в воскресенье на просторах одной российской социальной сети я увидел ссылку на статью — What I learned from writing six functions that all did the same thing (Что я узнал от написания шести функций которые делали одно и то же).

Lock-free list является основой многих интересных структур данных, — простейшего hash map, где lock-free list используется как список коллизий, split-ordered list, построенный целиком на списке с оригинальным алгоритмом расщепления bucket'а, многоуровневого skip list, являющегося по сути иерархическим списком списков. В предыдущей статье мы убедились, что можно придать такую внутреннюю структуру конкурентному контейнеру, чтобы он поддерживал thread-safe итераторы в динамичном мире lock-free контейнеров. Как мы выяснили, основным условием для того, чтобы lock-free контейнер стал итерабельным, является стабильность внутренней структуры: ноды не должны физически удаляться (delete). В этом случае итератор суть просто (быть может, составной) указатель на ноду с возможностью перехода к следующей (оператор инкремента).

Можно ли такой подход распространить на lock-free list?.. Посмотрим…

Это перевод обзора статьи «MemC3: Compact and Concurrent MemCache with Dumber Caching and Smarter Hashing» Fan et al. в Proceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI’13), pdf тут

Чуваки (бывший гугловец, чувак из университета Карнеги Меллон и еще один из Интел лабс) сделали улучшенный Memcached-совместимый кеш (по факту просто допилили мемкеш), и у них классные результаты производительности. Мне очень понравился обзор этой статьи в блоге "The morning paper" — описание алгоритмов и прочее.

"Обычно хакер пишет программы не ради выгоды,
а ради собственного удовольствия. Такая программа
может оказаться полезной, а может остаться
всего лишь игрой интеллекта."
Генри С. Уоррен. Алгоритмические трюки для программистов [1]

Сегодня мы продолжим наши заметки об Эльбрусе. Первую статью, посвященную запуску и оптимизации системы распознавания паспорта, можно прочитать тут.

Однажды мы с коллегами заинтересовались, как самые простые методы оптимизации работают на Эльбрусе.

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

Этот процесс должен быть достаточно быстрым, но вместе с тем и эффективным. Корпорация IBM заключила договор с Nvidia о совместном сотрудничестве, которое заключается в разработке программного обеспечения IBM Power AI. Это платформа, работающая на специализированном сервере IBM Power System S822LC на процессорах IBM Power 8. Такая программно-аппаратная платформа, по мнению специалистов, и должна обеспечивать быстрое глубокое обучение современных сетей.

В предыдущих частях опуса (1, 2, 3) мы рассмотрели внутреннее строение lock-free map и убедились, что все основные операции — поиск, добавление и удаление ключа — могут быть выполнены без глобальных блокировок и даже в lock-free манере. Но стандартный std::map поддерживает ещё одну очень полезную абстракцию — итераторы. Возможно ли реализовать итерабельный lock-free map?
Ответ на этот вопрос — под катом.

UPD. В связи с тем, что многие комментаторы не читают полностью, напишу здесь краткую суть проблемы: для .RU не очищаются Glue Records при изменении делегирования домена. Как минимум, для доменов, управляемых через Ru-Center и Reg.ru. Сама статья — это «история из жизни» о том, какие проблемы может вызвать такая «особенность» зоны .RU, как они были диагностированы и решены.

---

«Один мой друг» (с) рассказал историю про свои приключения с DNS.

Предыстория

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

Глава 1

Еще раз проверяем DNS зоны, убеждаемся, что нигде нет старых адресов и очень давно. Проверяем из разных регионов запросами на каждый из своих NS. Везде всё отдаётся правильно. Берем tcpdump и смотрим запросы на 53 порт на старыx DNS. Оказывается, что запросов к ним удивительно много. И это при том, что IP адреса этих серверов уже много месяцев нигде не фигурируют!

На протяжении порядка ста лет Патентное ведомство и Верховный Суд США посредством прецедентов борются и запрещают патентование абстрактных идей, природных явлений, математических алгоритмов как таковых. Тем не менее, потенциальные патентообладатели изо всех сил пытаются обмануть патентное ведомство и суды всех инстанций, стараясь не попасть в «запрещенные» категории, особенно в наше время с софтверными решениями, которые не являются материальными и очень легко могут быть отнесены к абстрактным идеям или программам.

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

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

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

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