Как стать автором
Обновить
37.4

Серверная оптимизация *

Разгружаем сервер

Сначала показывать
Порог рейтинга
Уровень сложности

Алгоритмы балансировки нагрузок

Уровень сложности Средний
Время на прочтение 8 мин
Количество просмотров 29K

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

В этом посте мы рассмотрим способы, которыми один балансировщик нагрузок может распределять HTTP-запросы на множество серверов. Мы начнём снизу и проделаем весь путь вверх до современных алгоритмов балансировки нагрузок.
Читать дальше →
Всего голосов 107: ↑106 и ↓1 +105
Комментарии 16

Новости

А все ли врут? Продолжаем издеваться над NVME

Время на прочтение 10 мин
Количество просмотров 37K

А пока мои коллеги пытаются разобраться с проблемами серверных NVME Raid массивов, я решил посмотреть на проблему с другого ракурса. Ведь NVME — это не только жёсткий диск, но и три-четыре протокола быстропередаваемых данных.

Для многих из нас nvme означает, что мы купили новый компьютер или ультрабук. Жёсткий диск, подключённый напрямую к шине PCIE, позволяет существенно снизить задержки передачи данных и ускорить любую систему. NVME — это ключ к загрузке любой системы за 3 секунды.

Но, на самом деле сам по себе NVME — это не стандарт для жёстких дисков. NVME расшифровывается как NVM Express. NVM, в свою очередь, означает Non-volatile memory, И в первую очередь — это спецификация протокола, который позволяет производить эффективный доступ к данным, хранящимся в энергонезависимой памяти.

А как мы хорошо знаем, протоколы можно запускать на разных носителях. В этой статье мы будем издеваться над моим лэптопом с Ubuntu Linux 21 на борту, подключая его жёсткий диск к разным серверам. Вы можете посетовать, что всё это игрушки, но хороший администратор со свитчем, позволяющим поддерживать скорости более 10 гигабит в секунду, должен взять это на заметку. Вы можете получить удалённый доступ к вашим nvme жёстким дискам через tcp/ip без уловок и мошенства.

Поехали.
Читать дальше →
Всего голосов 113: ↑113 и ↓0 +113
Комментарии 90

Неожиданные причины торможения программ и систем

Время на прочтение 29 мин
Количество просмотров 48K

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

Я назвал пост Surprisingly Slow потому, что замедление было для меня неожиданным, или неоптимальные практики, ведущие к замедлению, настолько распространены, что многие программисты будут удивлены их существованию.

Разделы поста чаще всего никак не связаны друг с другом, поэтому можете выбирать самые интересные для вас.
Читать дальше →
Всего голосов 112: ↑111 и ↓1 +110
Комментарии 88

Генератор неслучайных чисел

Время на прочтение 4 мин
Количество просмотров 20K
Этот код напечатает случайную последовательность латинских букв, так ведь?

import java.util.Random;

class WTF {
    public static void main(String[] args) {
        Random r = new Random(76880392499L<<11);
        String alphabet = " abcdefghijklmnopqrstuvwxyz";
        int n;
        while ((n = r.nextInt(alphabet.length())) > 0)
        	System.out.print(alphabet.charAt(n));
    }
}

Можете проверить; вывод кажется совсем не случайным. Как же так вышло?

Прежде всего: какой шанс, что из всех последовательностей латинских букв напечатается именно эта? Сгенерировано 10 случайных чисел, каждое выбиралось из 27 вариантов, значит всего вариантов было $27^{10} \approx 2.06\cdot10^{14}$. Если считать, что все варианты равновероятны, то нам выпал один шанс из двухсот миллионов миллионов! Ух!
Читать дальше →
Всего голосов 107: ↑104 и ↓3 +101
Комментарии 30

Истории

Хаки при работе с большим числом мелких файлов

Время на прочтение 7 мин
Количество просмотров 41K
Идея статьи родилась спонтанно из дискуссии в комментариях к статье «Кое-что об inode».



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

Поэтому делюсь нашим опытом, может кому и пригодится.
Читать дальше →
Всего голосов 104: ↑103 и ↓1 +102
Комментарии 66

htop и многое другое на пальцах

Время на прочтение 26 мин
Количество просмотров 275K


На протяжении долгого времени я не до конца понимал htop. Я думал, что средняя загрузка [load average] в 1.0 означает, что процессор загружен на 50%, но это не совсем так. Да и потом, почему именно 1.0?

Затем я решил во всём разобраться и написать об этом. Говорят, что лучший способ научиться новому — попытаться это объяснить.
Читать дальше →
Всего голосов 138: ↑130 и ↓8 +122
Комментарии 43

Твердотельные накопители дали слабину

Время на прочтение 3 мин
Количество просмотров 101K
Технологии хранения данных — отдельная тема. Не так давно мы косвенно затрагивали ее в нашем материале об управления дисковым пространством сервера.

Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.

Читать дальше →
Всего голосов 110: ↑107 и ↓3 +104
Комментарии 50

Как правильно мерять производительность диска

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

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

Лирика



Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:
  • научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
  • использование bonnie++
  • использование iozone
  • использование пачки cp с измерениема времени выполнения
  • использование iometer с dynamo на 64-битных системах


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

Как мерять правильно
Всего голосов 151: ↑145 и ↓6 +139
Комментарии 164

Я медленно удаляю apache с сервера

Время на прочтение 13 мин
Количество просмотров 54K
image
Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.
Если интересно - нажмите сюда, если нет - нажмите звездочку ниже
Всего голосов 167: ↑137 и ↓30 +107
Комментарии 184

6 способов убить Ваши сервера — познаем масштабируемость трудным путем

Время на прочтение 5 мин
Количество просмотров 18K
Узнать, как отмасштабировать Ваше приложение, не имея при этом никакого опыта, — это очень нелегко. Сейчас есть много сайтов, посвященных этим вопросам, но, к сожалению, не существует решения, которое подходит для всех случаев. Вам по-прежнему необходимо самому находить решения, которые подойдут под Ваши требования. Так же, как и мне.

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.
Читать дальше →
Всего голосов 158: ↑148 и ↓10 +138
Комментарии 73

Сервер на стероидах: FreeBSD, nginx, MySQL, PostgreSQL, PHP и многое другое

Время на прочтение 16 мин
Количество просмотров 40K
Нравится мне эта картинка, у меня, вот никогда такие красивые графики в какти не получались =(

Введение


С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Кому что-нибудь из этого списка интересно, жмём сюда...
Всего голосов 375: ↑368 и ↓7 +361
Комментарии 105

Прогрессивные технологии, как способ выжать из сервера максимум

Время на прочтение 5 мин
Количество просмотров 12K

Вступление


Просто красивый rrdtool =)
Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.
читать дальше
Всего голосов 318: ↑314 и ↓4 +310
Комментарии 184

Вклад авторов

Работа