Top-10 fails on real highload project

Данный доклад был представлен на Highload Fwdays'17 и я рассказал 10 историй о проблемах через которые я с командой прошел на реальном нагруженном проекте с миллионами пользователей.

Истории:
- как ошибка выбора идентификатора пользователя, обнаруженная после запуска проекта, чуть не стоила 2 лет разработки
- как мы боролись с перегруженным mysql когда даже включение binlog убивает сервер
- почистил партицию mysql под нагрузкой - получи мертвый сервер
- как верстальщик поменял верстку серча и уложил продукт на 4 часа
- ошибка в ядре php которая привела даунтайм на несколько часов
- как незнание особенностей работы GC у redis обошлось в $50к чистой прибыли
- добавлением или удалением серверов из пула memcached инвалидировали весь кэш (кривые настройки php клиента Memcache/Memcached)
- как поправив тест потерять 2 миллиона пользовательских писем
- как релиз одного проекта крэшил хелсчеки соседнего проекта
- самый большой фейл с системами очередей и статистикой: ивенты терялись годами

Transcript

1. Дмитрий Меньшиков Aurora Technologies Топ-10 фейлов на реальном highload проекте
2. Gray hat ACM CTF, freelance Senior Team lead Chef Technical Officer Автор журнала ][akep
3. # Как ошибка выбора идентификатора пользователя, обнаруженная после запуска проекта, чуть не стоила 2 лет разработки
4. >= 64 бит на id Отсутствие пересечений в разных дата центрах Получение новых id без опроса хранилища
5. Длина 128-bit v1: date + ^me + MAC address v2: random UUID
6. Размер индекса для хранения в БД? 100 000 000 224 ≈ 5.9
7. Размер индекса для хранения в БД? 100 000 000 224 ≈ 5.9 … как 3 байта сохранить
8. Данные перенесли Вскоре началось… Пользователей запустили
9. Размер индекса для хранения в БД? 100 000 000 224 ≈ 5.9
10. Размер индекса для хранения в БД? 100 000 000 224 ≈ 5.9
11. 200 SELECTIVITY фактически полученное значение
13. The timestamp is a 60-bit value. For UUID version 1, this is represented by UTC as a count of 100-nanosecond intervals since 00:00:00.00, 15 October.
15. 00110111010001101110000000001110 00110111010001101110000101011000 00110111010001101110001110010010 00110111010001101110010001111000 00110111010001101110011000011100 00110111010001101110011011101110 00110111010001101110100001110100
16. Big-endian vs li^le-endian, потому секундная фракция попала в начало Отсутствие равномерного распределения из-за особенностей генерации
17. Остановка миграции и отказ от переноса?
18. ???
19. УВЕЛИЧИТЬ ДЛИНУ ИНДЕКСА ДО 4 БАЙТ
20. # Как мы боролись с перегруженным MySQL когда даже включение binlog убивало сервер
21. Задача: сделать ALTER без блокировки Подключить slave Синхронизировать Вывести slave Сделать ALTER Поменять местами
22. Сервера были с i/o 85-90% Затем был включен binlog
23. Сервера были с i/o 85-90% Затем был включен binlog Включение binlog добило их
24. pt-online-schema-change от PERCONA *работает только с таблицами с PRIMARY KEY или UNIQUE INDEX Нужна альтернатива требующая меньше ресурсов
25. pt-online-schema-change от PERCONA *работает только с таблицами с PRIMARY KEY или UNIQUE INDEX OnlineSchemaChange от Facebook *работает только с таблицами с PRIMARY KEY или UNIQUE INDEX *позволяет переливать базы на другой сервер *отсутствует контроль скорости Нужна альтернатива требующая меньше ресурсов
27. За 4 (бессонных) суток мной была написана утилита*! * - без SMS и регистрации, первые 14 дней использования бесплатны, затем за каждый день взымается абонентская плата в размере $10000 ZWL.
28. Атомарно создаются триггера на INSERT, UPDATE, DELETE с записью изменений в delta-таблицы
29. Атомарно создаются триггера на INSERT, UPDATE, DELETE с записью изменений в delta-таблицы Начинается выборка данных, с регулятором скорости
30. Атомарно создаются триггера на INSERT, UPDATE, DELETE с записью изменений в delta-таблицы Начинается выборка данных, с регулятором скорости Импорт на des†na†on сервер дампа
31. Атомарно создаются триггера на INSERT, UPDATE, DELETE с записью изменений в delta-таблицы Начинается выборка данных, с регулятором скорости Импорт на des†na†on сервер дампа Загрузка данных с delta-таблиц
32. Атомарно создаются триггера на INSERT, UPDATE, DELETE с записью изменений в delta-таблицы Начинается выборка данных, с регулятором скорости Импорт на des†na†on сервер дампа Загрузка данных с delta-таблиц Переключение серверов или свитч баз
33. Еще 2 недели времени потребовалось дабы перетасовать базы с серверов на сервера
34. # Почистил таблицы MySQL под нагрузкой – получи мертвый сервер
36. Запросы все поступали, соединения устанавливались, очередь запросов росла В какой-то момент сервер перестал отвечать… Дежурный сделал TRUNCATE таблицы
38. TRUNCATE TABLE ставит lock на операции с table cache и buffer pool
39. Выполняет чистку по pages в buffer pool TRUNCATE TABLE ставит lock на операции с table cache и buffer pool
40. Выполняет чистку по pages в buffer pool Снимает блокировки в самом конце TRUNCATE TABLE ставит lock на операции с table cache и buffer pool
41. …В это время приходит DDL операция и ставится lock на table cache, а затем попытка установить lock на buffer pool… … которая будет ожидать завершения первого TRUNCATE
42. При этом table cache lock не снялся!
43. Следствие: все запросы в ожидании
44. Баг описан: h‹ps://bugs.mysql.com/bug.php?id=80060 h‹ps://bugs.mysql.com/bug.php?id=56696 Закрыт только в 5.7.18
45. Замедляться выполнение еще может из-за включенного adap†ve hash index Scan по buffer pool для чистки adap†ve hash index может выполняться долго h‹ps://bugs.mysql.com/bug.php?id=68184
46. Проблема не наблюдалась на серверах с небольшим размером buffer pool
47. Рекомендация v1: … Проблема не наблюдалась на серверах с небольшим размером buffer pool
48. Рекомендация v1: не транкейтить таблицы, партиции, а использовать DROP PARTITION Проблема не наблюдалась на серверах с небольшим размером buffer pool
49. Просадка порой наблюдается и с DROP PARTITION
50. Рекомендация v1: не транкейтить таблицы, партиции,а использовать DROP PARTITION Проблема не наблюдалась на серверах с небольшим размером buffer pool Рекомендация v2: использовать EXCHANGE PARTITION
51. # Релиз одного проекта и влияние на consul кластер в другом проекте
52. сервера в стойке подключены к стоечному свитчу кроссконнекты между свитчами разных стоек мир подключен к маршрутизатору и от него к свитчам rsync обновлений с билд машины
54. RIP consul
55. Шейпинг rsync Перегрузка гипервизоров ???
56. За решение дам билет
57. # О том как инвалидировался кэш memcached при добавлении/ удалении сервера в пул
58. server_id = hash(key) % num_servers hash может быть crc32, fnv, md5, murmur, etc Стандартный алгоритм в Memcache и Memcached:
59. h‹ps://www.adayinthelifeof.nl/2011/02/06/memcache-internals/ Consistent hashing
60. h‹ps://www.adayinthelifeof.nl/2011/02/06/memcache-internals/ Consistent hashing
61. h‹ps://www.adayinthelifeof.nl/2011/02/06/memcache-internals/ Consistent hashing
62. При стандартном потоке инвалидируется почти все При consistent hashing инвалидируется только 1/ N, где N – количество серверов в пуле
63. # Как незнание особенностей работы GC у redis обошлось в $50к чистой прибыли
64. Response ^me: mean 99th percen^le Response ^me: mean
65. Response ^me: mean 99th percen^le Response ^me: mean Response ^me: upper
67. Мы знали, что redis использует 1 CPU core Но не учли, что этот 1 CPU core использует и Garbage Collector
68. А он фризился на инстансе с сессиями на 2-5 секунд примерно раз в несколько минут Мы знали, что redis использует 1 CPU core Но не учли, что этот 1 CPU core использует и Garbage Collector
69. К моменту обнаружения поведение существовало несколько месяцев… QA не видели, так как нагрузка была вне рабочего времени
70. # Как верстальщик поменял верстку и уложил продукт на 4 часа
72. h‹p://photo.com/id/photoId? v=eyJ3aWR0aCI6MTYwLCJoZWlnaHQiOjE2M H0K eyJ3aWR0aCI6MTYwLCJoZWlnaH QiOjE2MH0K == base64(‘{"width":160,"height": 160}’)
73. А resize динамический!
77. # Ошибка в ядре PHP, что привела к даунтайму на несколько часов
79. Завис SoapServer партнера Наши PHP скрипты с SoapClient обращались на SoapServer Но не умирали по таймауту!
80. Код выглядел корректно, таймауты были: connec†on_†meout default_socket_†meout Но strace показывал, что клиент игнорирует настройки.
81. Разработчики забыли включить таймаут для HTTPS h‹ps://bugs.php.net/bug.php?id=48524
82. # Как поправить тест потерять 2 миллиона писем
84. # Архитектура системы сбора статистики
86. requests
87. requests
88. requests events data
89. Смена состояния системы при ошибке обработки с последующим nack Отсутствие очередности в доставке сообщений Purge очереди Hard reboot rabbitmq Включение auto acknowledgment в коде Факторы потери/порчи данных:
90. Как же жить с highload?
91. Как же жить с highload? Практически проверять внедряемые решения Думать как изменение может затронуть систему Собирать метрики и правильно анализировать их Инвестировать в знания
92. h‹ps://t.me/noTieinIT @noTieinIT h‹ps://¦.com/menshikov.life h‹p://dmenshikov.com
93. h‹ps://t.me/noTieinIT @noTieinIT h‹ps://¦.com/menshikov.life h‹p://dmenshikov.com ???