Документ описывает методы построения высокопроизводительного front-end сервера, включая атомарные операции, lock-free структуры данных и их влияние на производительность. Рассмотрены различные подходы к снижению lock contention, в том числе использование атомарных операций и lock-free очередей. Обсуждаются также вопросы привязки потоков к процессорам и реализация zero-copy сетевого ввода-вывода для повышения эффективности работы сервера.

1. Как построить высокопроизводительный front-end сервер Александр Крижановский NatSys Lab

2. Содержание Атомарные операции Снижение lock contention Lock-free структуры данных (FIFO/LIFO списки) Zero-copy network IO Аллокаторы памяти Привязка потоков/процессов к CPU

3. Front-end сервер: В основном работает только с RAM Как правило многопоточный Часто между потоками/процессами разделяется одна или несколько структур данных как на чтение, так и на запись

4. Front-end сервер:

5. Очередь Обычно 1 производитель , N потребителей Реализует только операции push() и pop() (нет сканирований по списку) Классический (наивный) вариант: std::queue , защищенный mutex 'ом Может быть реализована на атомарных операциях для снижения lock contention

6. Атомарные операции: стоимость Реализуются через протокол cache coherency (MESI) Писать в одну область памяти на разных процессорах дорого, т.к. процессоры должны обмениваться сообщениями RFO ( R equest F or O wnership)

7. Lock contention Один процесс удерживает лок, другие процессы ждут — система становится однопроцессной Актуален с увеличением числа вычислительных ядер (или потоков исполнения) и числом блокировок в программе Признак: ресурсы сервера используются слабо (CPU, IO etc), но число RPS невысокий Методы борьбы: увеличение гранулярности блокировок, использование более легких методов синхронизации

8. Блокировки pthread_mutex , pthread_rwlock - используют futex(2) , достаточно тяжеловестны сами по себе pthread_spinlock («busy loop») — в ядре ОС используется в сочетании с запретом вытеснения, в user space может привести к нежалательным последствиям Атомарные операции , барьеры и double-check locking — наиболее легкие, но все равно не «бесплатны»

9. Атомарные операции ( R ead- M odify- W rite) unsigned long a, b = 1; a = __sync_fetch_and_add (&a, 1); mov $0x1,%edx lock xadd %rdx,(%rax)

10. Атомарные операции ( C ompare- A nd- S wap) unsigned long val = 5; __sync_val_compare_and_swap (&val, 5, 2); mov $0x5,%eax mov $0x2,%ecx lock cmpxchg %rcx,(%rdx)

11. Атомарные операции: стоимость Реализуются через протокол cache coherency (MESI) Писать в одну область памяти на разных процессорах дорого, т.к. процессоры должны обмениваться сообщениями RFO ( R equest F or O wnership) Используются в shared_ptr для reference counting

12. Lock-free очередь (список) push (ff: pointer to fifo, cl: pointer to cell): Loop: cl->next = ff->tail if CAS (&ff->tail, cl->next, cl): break

13. Lock-free очередь (список) pop (ff: pointer to fifo): Loop: cl = ff->head next = cl->next if CAS (&ff->head, cl, next): break return cl

14. ABA problem Поток T1 читает значение A, T1 вытесняется, позволяя выполняться T2, T2 меняет значение A на B и обратно на A, T1 возобновляет работу, видит, что значение не изменилось, и продолжает…

15. Lock-free очередь: ABA pop (ff: pointer to fifo): Loop: cl = ff->head next = cl->next # cl = A, next = B ------------------->scheduled # pop(A), pop(B), push(A) if CAS (&ff->head, cl, next) : # cl->head => B (вместо C) break return cl

16. Решение ABA Вводятся счетчики числа pop()'ов и push()'ей для всей структуры или отдельных элементов и атомарно сравниваются Нужна операция CAS2 (Double CAS) для сравнения двух операндов: CMPXCHG16B на x86-64

17. Lock-free очередь (ring-buffer)

18. Lock-free очередь (список vs ring-buffer) Ring-buffer сложнее в реализации (требуется синхронизированное передвижение указателей на tail и head для каждого из потоков) Список должен быть интрузивным для избежания аллокации узлов на каждой вставке Для списка нужно отдельно реализовать контроль числа элементов Локализация и выравнивание памяти - ?

19. Lock-free очередь (только) Работает только для очередей — сканировать такие структуры данных без блокировок нельзя Для очереди нужна реализация ожидания: usleep(1000) — помещение потока в wait queue на примерно один такт системного таймера sched_yield() - busy loop на перепланирование (100% CPU usage)

20. Кэш Hash table, RB-tree, T-tree, хэш деревьев и пр. Lock contention снижается путем введения отдельных блокировок для каждого bucket'а хэша или поддерева Часто нужно вытеснение элементов : Hash table как список или спикок + основная структура данных RW-блокировки, ленивые блокировки

21. Zero-copy Network (I)O

22. vmsplice()/splice() Только на Output, на Input memcpy() в ядре Сетевой стек пишет данные напрямую со страницы => перед использованием страницы снова нужно записать 2 размера буфера отправки ( double-buffer write )

23. Splice:производительность # ./nettest/xmit -s65536 -p1000000 127.0.0.1 5500 xmit: msg=64kb, packets=1000000 vmsplice() -> splice() usr=9259, sys= 6864 , real=27973 # ./nettest/xmit -s65536 -p1000000 -n 127.0.0.1 5500 xmit: msg=64kb, packets=1000000 send() usr=8762, sys= 25497 , real=34261

24. Когда полезны свои аллокаторы Специальный аллокатор, позволяющий читать из сокета по несколько сообщений и освобождать весь кусок разом (страницы + referece counting) Page allocator для работы c vmsplice/splice SLAB-аллокатор для объектов одинакового размера Boost::pool (частный случай SLAB-аллокатора): пул объектов одинакового размера, освобождаемых одновременно

25. CPU binding (interrupts) APIC балансирует нагрузку между свободными ядрами Irqbalance умеет привязывать прерывания в зависимости от процессорной топологии и текущей нагрузки => не следует привязывать прерывания руками Прерывание обрабатывается локальным softirq, прикладной процесс мигрирует на этот же CPU Cpu9 : 13.3%us, 62.1%sy , 0.0%ni, 1.0%id, 0.0%wa, 0.0%hi, 23.6%si , 0.0%st Cpu10 : 0.0%us, 0.7%sy, 0.0%ni, 82.7%id, 0.0%wa, 0.0%hi, 16.6%si , 0.0%st

26. CPU binding (процессы) Не имеет смысла создавать больше тредов, чем физических ядер процессора для улучшения cache hit Часто кэши процессора разделяются ядрами (L2, L3) Шины между ядрами одного процессора заметно быстрее шины между процессорами => worker'ов (разделяющих кэш) лучше привязывать к ядрам одного процессора.

27. CPU binding: пример # dd if=/dev/zero count=2000000 bs=8192 | nc 10.10.10.10 7700 16384000000 bytes (16 GB) copied, 59.4648 seconds, 276 MB/s # taskset 0x400 dd if=/dev/zero count=2000000 bs=8192 \ | taskset 0x200 nc 10.10.10.10 7700 16384000000 bytes (16 GB) copied, 39.8281 seconds, 411 MB/s

28. Спасибо! [email_address]