Топология памяти
Очень часто вижу подход к серверам и вычислительной инфраструктуре на кухонном уровне даже от вроде бы профессиональных людей с высочайшими ЗП в полмиллиона и выше.
Сервер - это просто большой макбук, а СХД просто большой диск.
Итак, давайте разбираться. И начнем со страшной темы - топология памяти.
Объяснять буду реально на желудях и шишках, поэтому сразу просьба к крутым суперпрофи - не надо пытаться меня уличить, это не для вас написано.
Если увеличить число процессорных ядер в 1,5 раза, не трогая ничего остального — как изменится время сборки проекта?
Читать полностью »
Масштабирование СУБД – это непрерывно наступающее будущее. СУБД совершенствуются и лучше масштабируются на аппаратных платформах, а сами аппаратные платформы наращивают производительность, число ядер, памяти — Ахиллес догоняет черепаху, но все еще не догнал. Проблема масштабирования СУБД стоит во весь рост.
Компании Postgres Professional с проблемой масштабирования довелось столкнуться не только теоретически, но и практически: у своих заказчиков. И не раз. Об одном из таких случаев и пойдёт речь в этой статье.
PostgreSQL неплохо масштабируется на NUMA-системах, если это одна материнская плата с несколькими процессорами и несколькими шинами данных. О некоторых оптимизациях можно почитать здесь и здесь. Однако есть и другой класс систем, у них несколько материнских плат, обмен данными между которыми осуществляется с помощью интерконнекта, при этом на них работает один экземпляр ОС и для пользователя такая конструкция выглядит как единая машина. И хотя формально такие системы можно также отнести к NUMA, но по своей сути они ближе к суперкомпьютерам, т.к. доступ к локальной памяти узла и доступ к памяти соседнего узла отличаются радикально. В сообществе PostgreSQL считают, что единственный экземпляр Postgrs, работающий на таких архитектурах, это источник проблем, и системного подхода к их решению пока нет.
Читать полностью »
Представлен выпуск проекта netutils-linux 2.5.0, набора утилит для мониторинга и тюнинга производительности сетевого стека Linux. Всё написано на Python (поддерживаются python 2.6+ и 3.4+) и доступно под MIT-лицензией.
Цель проекта — упростить и унифицировать процесс тюнинга сетевого стека и сетевых карт, снизив необходимость разбираться в устройстве сетевого стека для сисадминов и освободить их головы от рутинных вычислений и написания с нуля кучи одинаковых bash-скриптов.
Рекомендации для использования — наличие канала с 200+ Мбит/с, обрабатываемого Linux-based машиной, и требований к минимизации задержек и потерь.
С прошлого (и первого) публичного релиза было исправлено несколько неприятных ошибок, связанных с совместимостью с архитектурами, дистрибутивами Linux, версиями Python и зависимостей проекта, приводивших к невозможностям запуска некоторых утилит.
Сетевой стек Linux по умолчанию замечательно работает на десктопах. На серверах с нагрузкой чуть выше средней уже приходится разбираться как всё нужно правильно настраивать. На моей текущей работе этим приходится заниматься едва ли не в промышленных масштабах, так что без автоматизации никуда – объяснять каждому коллеге что и как устроено долго, а заставлять людей читать ≈300 страниц английского текста, перемешанного с кодом на C… Можно и нужно, но результаты будут не через час и не через день. Поэтому я попробовал накидать набор утилит для тюнинга сетевого стека и руководство по их использованию, не уходящее в специфические детали определённых задач, которое при этом остаётся достаточно компактным для того, чтобы его можно было прочитать меньше чем за час и вынести из него хоть какую-то пользу.
Самая приятная часть в хакатоне – это призы, а призы бывают разные. В основном их объединяет одна штука — их мало. На всех не хватает. И после over700 хакатонов наклеечки, футболки и кружки уже как-то приедаются. В этот раз что-то новое: коллеги из NUMA Moscow проводят хакатон с AccorHotels (кто не знает – это всякие модные Ibis, Novotel, Mercury), что тоже в новинку – отельных хакатонов я у нас не помню. Для того что бы выиграть поездку в земли варёных лягушек и металлической башни надо собрать команду (в идеале два мальчика + две девочки) и выиграть. Ничего сложного.
