performance optimisations

20 Сентябрь, 2012

Антон ПавленкоРуководитель экспертной группы

Анализ производительностиКраткий путеводитель

© 2012 Инфосистемы ДжетСервисный центр

Вы знаете ответы на эти вопросы?

Сколько пользователей у вашей системы?

Сколько из них заходят одновременно?

Какой запас по прочности?

Вы знаете когда он закончится?

Какое время отклика устраивает ваших клиентов?

Вы мониторите превышение времени отклика?

….......


О чем хочу рассказать

Анализ производительности : повышает предсказуемость работы системы позволяет оценить запас прочности помогает планировать финансы позволяет выявить узкие места

И самое главное:

Выявив и устранив узкое место можно существенно сэкономить


Bottleneck и все все все

Узкое место — явление, при котором производительность или пропускная способность системы ограничена одним или несколькими компонентами или ресурсами. (с) WikiPedia


Время отклика системы

типичый график зависимости времениотклика от нагрузки.

График зависимости хорошо спроектированной системы


Производительность системы


У разных приложений разные требования

Приложения бывают :- CPU bound- IO bound ( Network, Disk )

При этом ключевым фактором может быть :- latency- throughput


Теперь о CPU


Что важно знать про CPU

Так ли важна частота CPU?

Возможности масштабирования значительно отличаются ( как и latency при обращении к «чужой» памяти )

Процессор это не только CPU но и интегрированные элементы ( сеть, интерфейс к памяти, модуль шифрования )

Каждый процессор обладает уникальными свойствами, использование которых позволяет повысить производительность приложения ( SSE 4.2, prefetch инструкции, out-of-order execution, branch prediction, … )


SMP и NUMA


Давайте поговорим про RAM


цепочка обращений к памяти

Processor Regs L1 d-cache

L1 i-cache

UnifiedL2

Cache

UnifiedL2

CacheMemoryMemory diskdisk

size:speed:line size:

200 B3 ns8 B

8-64 KB3 ns32 B

1-4MB SRAM6 ns32 B

128 MB DRAM60-70 ns8 KB

30 GB8-10 ms

Быстрее, выше, сильнее Больше, медленее, дешевле


Что нужно знать про RAM

Как соотносятся времена доступа

Память работает не байтами

Существует L1/L2 кеш

Кеш вымывается

Обращения к памяти стоит выравнивать

Существует ( и даже иногда работает ) префетч


Время доступа к RAM

Bandwidth. линейное чтение4.6 GB/sec на лаптопе, ~12.7 GB/sec на сервере

* На серверах можно настраивать interleaving, который повышает скорость линейного чтения

Latency.

Читаем 100M блоком int32, шаг 4096195 MB/sec, 2.14 sec/100M, ~49 Mreads/sec

последовательный доступ ~1-2 такта

случайный доступ ~40-60 тактов

Почему так?


RAM и L1 cache

Потому что существует L1/L2 cache

Скачем с шагом N => кеш-миссы => тормоза

Шаг 4..64, ~4400..330 MB/sec, ~2x/шаг

Шаг 64..1024, ~330..195 MB/sec

P.S: для CPU с размером L1 кеш-линии 64 байта


RAM и L2 cache

Фиксируем шаг 1024, уменьшаем данные

100M, …, 4M, 3M, 2.3M == 195 MB/sec

2M == 648 MB/sec

1M == 1688 MB/sec

512K == 1724 MB/sec

Все сходится, размер L2 cache 2MB

При чём тут выравнивание?


RAM и L3 cache

Ну вы поняли


Параметры cpu cache

Коэфициент промаха Доля обращений к памяти, не найденных в кеше

(misses/references) Средние часла:

3-10% для L1Может быть очень маленьким ( < 1%) для L2, зависит от

размера, и т.д..

Hit Time Время “доставки” линии кеша в “процессор” (включает время

определения есть ли данные в кеше) Типичные цифры:

1 clock cycle для L13-8 clock cycles для L2

Miss Penalty Необходимо дополнительное время в случае промаха

25-100 cycles для основной памяти (RAM )


Совсем немного о дисках

Диски, они механические => медленные


И еще чуть чуть о дисках

Размер не имеет значения ( чаще всего )

Для большинства приложений важным показателем является количетсво IOPS'ов а не Mb/s

Latency напрямую зависит от размера блока

Несколько различных профилей нагрузки увеличивает время отклика для каждого обращения

Диски иногда ломаются

SSD бывают разные ( MLC и SLC NAND, DRAM, etc )


Что же делать с IO?

Учитывать требования при проектировании :Если для приложения критично latency то данные не должны читаться с диска ( Oracle SGA, in memory database, etc, etc, etc ) Если же критично throughput то важно помнить про выравнивание, использовать memory intterleaving, работать с данными парралельно ( striping )


Что же делать с IO?

Если все уже спроектировано до нас?

Оптимизировать!- Использовать большие страницы для уменьшения cache miss- Менять параметры выделения памяти для БД на серверах с архитектурой NUMA- Использовать специализированные аллокаторы памяти для многопоточных приложений- и так далее. Приёмов очень много.


О чём я сейчас рассказывал?


Для разных задач …


… разные инструменты


Выводы

Не все сервера одинаково полезны

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

Даже небольшие изменения могут привести к существенному росту/падению производительности

Вопросы?

Антон Павленко

http://jetservice.ru

[email protected]


Запасные слайды


Intel Core architecture

L1 cache : 64kb на ядроL2 cache : 1-8Mb (общий)L3 cache : 8-16Mb (общий) и не во всех процессорахНет HTПотомок архитектуры Pentium Pro :-)

4 ядра ( 6 в одной реализации )


Intel Nehalem architecture

L1 cache : 64kb на ядроL2 cache : 256Kb на ядроL3 cache : 4-12Mb (общий)Снова появился Hiper-threading!Появился QuickPath (до 8 ядер )Стал NUMAПоявился TLB! ( 512 ), но только для «маленьких» страниц ( 4K )Доступ к «чужой» памяти дороже в 1.5 раза

В Sandy Bridge :Больше L3 cache ( до 20 Мб )Доступ до L1 — 3 тика,До L2 - 8


Power 7

L1 cache 64 Кб на ядроL2 cache 256 Кб на ядроL3 cache 32 Мб ( разделен, но доступ есть у всех ядер )До 8 ядер по 4 потока на ядроL3 реализован через eDRAMВозможен интерконнект до 32 процессоровTLB size = 512 items 4-WAY

Power 6 был двухядерныйSparc T4 :L1 - 32Kb для ядраL2 — 128Kb на ядроL3 - 4Mb

performance optimisations

Technology