talks   10911

« earlier    

The Lead Developer London 2018
The conference for technical leads.
talks 
3 days ago by pietvanzoen
Evaluating the Evaluation: A Benchmarking Checklist
A co-worker introduced me to Craig Hanson and Pat Crain's performance mantras, which neatly summarize much of what we do in performance analysis and tuning. They are:

Performance mantras

Don't do it
Do it, but don't do it again
Do it less
Do it later
Do it when they're not looking
Do it concurrently
Do it cheaper

Perhaps you're choosing products based on benchmark results, or building a product and publishing your own benchmarks. I recommend using the following benchmarking questions as a checklist:

Benchmarking checklist

Why not double?
Did it break limits?
Did it error?
Does it reproduce?
Does it matter?
Did it even happen?
sysadm  performance  benchmark  tuning  talks 
5 days ago by some_hren
Lead Developer London 2018
Phil's notes from Lead Dev 2018
talks 
6 days ago by mhl
Dave Thomas: Keynote - Noddy
Libraries, components, and assemblies in Elixir. A proposal with a partially working proof of concept.
elixir  talks 
7 days ago by tjstankus
«20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет / Хабр
Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.
...
Дисковая система куплена дорогая и, вроде даже как-то настроена.

Ан нет. Крокодил не ловится, не растет кокос, и производительность системы такая же или ниже чем на старом сервере. Смотрю в sys.dm_os_waitsats и вижу WRITELOG, PAGEIOLATCH_SH и PAGEIOLATCH_EX в топе, среднее время ожидания 5+ мс. Ну типично, чо: "Эй, админы и DBA, тут у вас дисковая система — bottleneck" и вот тут начинается старая песня про 5 мс:


У нас 5 мс по SLA
Да у нас полка 20000 IOPS тащит
Нам вендор сказал, что все файлы БД можно на один раздел
У нас виртуализация и гиперконвергентность и мы не можем выделять отдельные диски под БД
По нашим данным утилизация сервера 5%
Всё настроено по рекомендациям
Вашим БД не нужна большая производительность, она не делает больше 300 IOPS (а у нас же полка на 20000 IOPS)

Кстати, всё вышесказанное не только про "свои" сервера, но и про облачные сервисы и виртуализацию. Там есть кучка своей специфики, но типичная клиническая картина примерно та же: в меру оптимизированная БД, неглупые сотрудники разработки и сопровождения, по процессору и памяти резерв есть, "выхлоп" от дальнейших вложений почти равен нулю.


Так вот. Эта вся песня про "5 мс" чушь и ерунда. Если вы сами такое говорите — читайте эту статью. А если вам такое говорят — готовьте аргументы. Раньше, когда я слышал эти слова, я злился, но я уже не злюсь. У меня, как у того горшка с петуньей из "Автостопом по галактике" только одна мысль: "Ну вот опять...".
...
Для OLTP систем на разделе с WAL/журналами транзакций 5 мс это недопустимый показатель. На "почти-коммодити" железяке за цену в 1000 (прописью: в тысячу) раз дешевле нормальным показателем сейчас будет 0,1-0,3 мс. А завтра — 0,01 мс. Скорость, как у HDD 2008 года по цене целого подъезда квартир в Москве не нужна. Никакое "удобство обслуживания" этого не стоит.
Вендор пишет, что журналы транзакций не требовательны к IOPS и их можно положить на HDD? Да, это так. Но для этого надо чтобы эти диски ни одна зараза задача кроме записи журналов СУБД не трогала. И чтобы СХД отвечала серверу, что данные записаны, сразу как данные легли в энергонезависимую память (это гораздо раньше, чем они будут записаны)
"Тонкие" диски для реальных OLTP БД — зло.
Для WAL абсолютно неинтересно сколько там можно выжать IOPS на глубине очереди 10 или 20. Там нет глубины.
Для WAL абсолютно не показатель, что очередь IO в ОС "всего лишь около 1". Она не будет больше.
...
Средняя задержка на разделе с WAL никогда не будет в секунду больше транзакций, чем:
5 мс 200
1 мс 1000
0,5 мс 2000
0,1 мс 10000
0,05 мс 20000
...
Делить дисковое пространство на LUN — это не прихоть DBA. У базы данных есть несколько разных профилей нагрузки дисковой подсистемы. Как минимум можно выделить следующее:
...
Ознакомьтесь с рекомендациями производителя СХД и СУБД, постарайтесь разобраться "почему они так советуют" и спроектируйте систему с учетом разных видов нагрузки. Разнесите принципиально разные виды нагрузки на разные разделы.
...
Latency почти всегда важнее throughput. И это продолжает быть верным и в облачных технологиях, и в "гиперконвергентных системах", и виртуальных фермах. Если вы улучшаете throughput увеличивая latency, то скорее всего ошибаетесь. Такое делать можно только очень обоснованно.
...
На горизонте есть очень интересный новый участник борьбы за производительность систем хранения для БД. Это Intel Optane. У нынешних SSD "красивые" цифры производительности начинаются от глубины очереди 4, что на самом деле не очень жизненно. Плюс эта производительность на запись обеспечивается некоторым объёмом оперативной памяти внутри SSD, и, если запись идёт достаточно интенсивно, то потом наступает существенная деградация производительности. А еще у SSD ограничен ресурс. Да, у современных серверных и топовых "гражданских" он достаточно большой, но совсем не бесконечный. И тут на сцене появляется Intel Optane: судя по тестам несерверных моделей (раз, два ) задержки на случайных операциях на очереди глубины 1 выходят на уровень около 20 микросекунд. Это по сути без кеширования, без деградации. SSD при таком же профиле начинают тупить до 100-300 мкс. Ресурс уже сейчас выходит за типичный ресурс SSD.
Ну цена, да. Но потенциально эта железка открывает новые горизонты производительности OLTP "традиционной", не in-memory архитектуры без отказа от ACID. А с другой стороны latency 20 мкс заставляет задуматься о судьбе "обычных" СХД. На low-latency требованиях им будет очень тяжело конкурировать с Optane (снова привет встроенным системам хранения?).
Это всё очень круто и я надеюсь на успех (и подешевление) Optane.
...
Статья и да, и нет.

Да — если вы мне продадите устройства, у которых в fsync-режиме (iodepth=1, block=4k, random write 100%) гарантированная минимальная latency 5ms, я буду просто счастлив. Почему? Потому что на современных устройствах (SSD, NVME), пики в реальных бенчмарках оказываются в районе секунд, в идеальных случаях — в районе многих сотен милисекунд.

fsync — критическое. Например, первый попавшийся SSD диск выдаёт мне 50кIOPS на запись. sustained, iodepht=32, span=100%, randow write 100%, blocksize=4k.

Но стоит в конфиг теста написать fsync=1… [more]
vmware  vsan  benchmark  talks  storage  ssd  database  performance  oracle  optane 
8 days ago by some_hren
Как мы тестировали VMware vSAN™: для чего это подходит на практике / Блог компании КРОК / Хабр
1. Описание железа. Например:
Сервера – 4xDellR630, в каждом:
• 2xE5-2680v4
• 128GB RAM
• 2x10GbE
• 2x1GbE for management/VM Network
• Dell HBA330
Storage Config #1:
2xPM1725 800GB
6xToshiba HK4E 1.6TB
Storage Config #2:
1xPM1725 800GB
6xToshiba HK4E 1.6TB

2. Описание версий ПО:
vSphere 6.5U1 (7967591) (vSAN 6.6.1), т.е. патчи после Meltdown/Spectre
vCenter 6.5U1g
Latest supported drivers and FW by vSAN and ESXi for all components
LACP for vSAN and vMotion traffic (with NIOC shares/limits/reservation enabled)
All other setting are default

3. Параметры нагрузки:
• HCIBench 1.6.6
• Oracle Vdbench — 5.04.06
• 40VM per cluster (10 per node)
• 10 vmdk per VM
• 10GB size of vmdk and 100/50/25% Workload set percentage
• Warmup time-1800sec (0.5 hour), Test time 3600 (1 hour)
• 1 Threads per vmdk
vmware  vsan  talks  benchmark 
8 days ago by some_hren
только бойкот: mi3ch
Получил письмо с просьбой прокомментировать наличие запасного аэродрома (второго гражданства, недвижимости за границей) у многих работников центрального телевидения – от Соловьева до Урганта.

С моей точки зрения это не имеет никакого значения. Все сотрудники центральных каналов являются мразями и подонками не из-за второго гражданства. А потому, что они работают на Геббельс-ТВ, которое занимается преступлением против своего народа – его обманом и растлением. Именно эти люди виновны в культе Путина. Именно они ответственны за войну с Украиной.

А тот факт, что лично милейший и остроумнейший Ваня Ургант или почтенный и импозантный Владимир Познер не принимали прямого участия во всей этой мерзости, не делает их порядочными людьми. Их роль даже омерзительнее, чем роль откровенных пропагандистов – они придают лоск и респектабельность этому Министерству Правды. И чтение ими Марселя Пруста и Людвига Витгенштейна в данном случае является не смягчающим, а отягчающим обстоятельством.
Это мое личное оценочное мнение.
russian  society  talks 
9 days ago by some_hren

« earlier    

related tags

2018-06-06  2018  ai  alan  alankay  amaze2018  amaze2019  apollo  application  architecture  audio  autoboxing  automatic-differentiation  bandits  benchmark  brain  business  c++  career  change  clojure  company  computer-science  conal-elliot  concurrentprogramming  conference  conferences  counterfactual-learning  creativity  crypto  database  databases  dates  ddd  deep-learning  design  dev  development  differentiation  distributedsystems  domains  education  elc  elixir  emigration  emilyshort  engineering  english  entrepreneur  entrepreneurship  erfurt  event-sourcing  favorites  films  financial  formik  freemonad  functional-programming  functional  games  gdc  go  golang  gpg  graphql  guidelines  hardware  history  influxdb  insight  insights  inspiration  institute  intepretable  java  job  kay  knowledge  kubernetes  languages  latered  leaddevlondon  learning  lecture  legacy  lessons  linklist  linux  lists  lockfreeprogramming  logging  loosemore  love  machine-translation  making  management  math  medium  meetupik  metrics  ml  mobile  mobx  monitoring  monoliths  nancy  networking  neural-net  nosql  notes  objectorientedprogramming  observability  opensource  optane  oracle  org-mode  parallelprogramming  performance  peter-bourgon  php  podcast  presale  presentaciones  presentations  procedural  process  products  programming  programminglanguages  prometheus  psychology  public-speaking  publishing  racket  rails  react-form-components  react  recordings  redux  relationship  resume  russian  salary  samba  sambaxp  science  security  seminar  serialization  slides  society  software  softwareengineering  speaking  sql  ssd  state  storage  storytelling  style  swdev  sysadm  tactics  talk  tanyashort  tech  testing  theleaddeveloper  thex  thueringenkreaktiv  tickets  time  tips  tracing  tuning  tuxcon  types  typescript  unsaved  video  videos  vmware  vsan  web  webinar  work  workshops  writing  youtube  youtubevideos  zabbix 

Copy this bookmark:



description:


tags: