Pull to refresh
29
0
Viacheslav Biriukov @brkov

Linux, systems programming

Send message
  1. Реального кода на С всё меньше и меньше (и это хорошо). Мне лично приятнее писать на более современных языках

  2. Чуть более про mmap есть далее в оригинальной серии. В этой главе только базовые примеры.

Спасибо за комментарий.

Пожалуйта, не уверен, что буду продолжать перводы. Тема не очень набрала, но вы всегда можете дочитать серию в оригинале.

Можно делать так, но никто вам не гарантирует сохранность данных в этом случае.

Спасибо за комментарий, если мы говорим о проде и контейнеах, а не примерах API, то да, вся ситуация намного интересней. Но, как правило, с одним файлом вы работаете из одного контейнера/cgroup'ы, у которой по хорошему, должный быть настроены все лимиты, в том числе и по IO. По сути вы в своём контейнере как будт-то одни на маашине.

В оригинале я касаюсь этих тем дальше по ходу статей. Если интерено, можете почитать оригинал

Всё это конечно прекрасно, но на уровне вопроса: что быстрее в php – echo или print?
Да unix сокеты "типа" быстрее, однако вся эта быстрота быстро нивелируется отсутствием нормальных инструментов дебага общения через него.
Да и мне лень смотреть в код, но если не изменяет память, там как-то всё очень плохо с backlog'ом. И бёрсты такая конструкция будет дропать.
dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_rpl_semi_sync_master_wait_point

AFTER_COMMIT: The master writes each transaction to its binary log and the slave, syncs the binary log, and commits the transaction to the storage engine. The master waits for slave acknowledgment of transaction receipt after the commit. Upon receiving acknowledgment, the master returns a result to the client, which then can proceed.

With AFTER_COMMIT, the client issuing the transaction gets a return status only after the server commits to the storage engine and receives slave acknowledgment. After the commit and before slave acknowledgment, other clients can see the committed transaction before the committing client.


Кажется вместе с sysvar_rpl_semi_sync_master_wait_for_slave_count можно добиться нормальной работы для бложиков и не бояться балансеров и прочего.
Semisynchronous Replication не спасёт от описанного кейса если слейвов больше чем один это раз. И два слейв может отставать.
У haproxy очень развесистая и настраеваемая архитектура в месте взаимодействия процессов системы между собой.
И с помощью правильно подобранных значений параметров: process, bind-process и nbproc ( www.haproxy.org/download/1.6/doc/management.txt, www.haproxy.org/download/1.6/doc/configuration.txt) можно добиться того же поведения, что используется в логике nginx.
Использование же параметра сокета SO_REUSEPORT, о которой говорится в статье от yelp, с одной стороны позволяет получить уменьшение лейтенси ответа и улучшения среднеквадратического отклонения, а с другой по понятным причинам создаёт почву для фейлов запросов. Около ~0.01% по данным haproxy:
Typically observed failure rates are around
1 failure during a reload operation every 10000 new connections per second,
which means that a heavily loaded site running at 30000 new connections per
second may see about 3 failed connection upon every reload.

В официальном блоге nginx про это тоже есть статья, описывающая полезность SO_REUSEPORT: www.nginx.com/blog/socket-sharding-nginx-release-1-9-1
В том, что при внезапном одноразовом чтении файлов с диска (например бэкап) система не вынесет из page cache горячии страницы.
вводит в заблуждение, потому что физически аллоцированная память точно так же идет через таблицу, а не «напрямую».

Да, вы правы, идёт через таблицу. Здесь идея была показать как и когда срабатывает page fault и demand paging и не усложнить картинку.

Почему чтения в кучу — больше переключений контекста? Или я чего-то не понимаю, или имелись ввиду переключения режима (user/kernel mode switch), что не одно и то же с context switch и близко.


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

Если mmap() такой распрекрасный, желательно вербализировать, зачем же кто-то все таки читает в юзер-спейс буффера. В моем понимании, это:


mmap() и впрямь распрекрасный =). Однако с ним есть тонкости. Невозможно, к примеру, отдебажить повторное обращение к данным, если они уже есть в pagecache и не вытеснились. С read'ами делается легко через I/O counter (/proc/self/io).

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


Да, так и есть, запись усложняется. Нам необходимо обновить журнал/лог_транзакций заранее и в append режиме (чтобы облегчить запись на диск). Но, кажется, что с переходом на SSD это становится меньшей проблемой. Посмотрите как это решили разработчики MongoDB: www.youtube.com/watch?feature=player_embedded&v=8TmmEzm50cw

Из минусов работы с mmap() я бы ещё добавил необходимость преаллоцировать файлы (опять же пример MongoDB) и дополнительные/ненужные page falts при записи в пустые области.

— Какие-то эвристики по вытеснению, более продвинутые чем LRU/2, или что там, имея на руках логику того, что конкретная страница представляет из себя для базы. + Возможность конфигурации этого дела.


Да это как раз то, что делают ребяза из InnoDB в MySQL: открывают файлы через O_DIRECT и реализуют всю эвристику под свои структуры данных.

Вообще этот аглоритм с LRU/2 и mmap() не позволяет иметь ваш Working set больше чем, грубо говоря, половина памяти. Есть различные идеи в ядре как это чинить. У нас это делается при помощи cgroup и патчей на ядро.

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


Не все. Отключать page cache плохо хотя бы потому, что это затрудняет деплой/обновление программы базы данных. Так у вас все данные в памяти и о ней знает ядро. А при выключенном кеше память приложения анонимна и потеряется при рестарте. Ну или придумываем вот такие штуки www.percona.com/doc/percona-server/5.5/management/innodb_lru_dump_restore.html

Information

Rating
Does not participate
Registered
Activity