Download to read offline
![Gray hat
ACM
CTF, freelance
Senior
Team lead
Chef Technical Officer
Автор журнала ][akep](https://image.slidesharecdn.com/a11-50menshikov-171018185250/85/10-highload-2-320.jpg)
Uploaded byFwdays
Дмитрий Меньшиков "Топ-10 фейлов на реальном highload проекте"
Документ описывает опыт и проблемы, возникшие в процессе разработки и эксплуатации высоконагруженного проекта, включая ошибки в выборе идентификаторов пользователя, сложности с MySQL и Redis, а также последствия неправильной архитектуры системы. Приводятся примеры сбоев, таких как зависание серверов и потеря данных, а также предлагаются решения и рекомендации по управлению нагрузкой. Автор подчеркивает важность тщательной проверки внедряемых решений и мониторинга метрик для успешного управления высоконагруженными системами.
More Related Content
Similar to Дмитрий Меньшиков "Топ-10 фейлов на реальном highload проекте"
Дмитрий Меньшиков "Топ-10 фейлов на реальном highload проекте"
- 1. Дмитрий Меньшиков Aurora Technologies Топ-10фейлов на реальном highload проекте
- 2. Gray hat ACM CTF, freelance Senior Teamlead Chef Technical Officer Автор журнала ][akep
- 3. Как ошибка выбораидентификатора пользователя, обнаруженная после запуска проекта, чуть не стоила 2 лет разработки
- 4. >= 64 битна id Отсутствие пересечений в разных дата центрах Получение новых id без опроса хранилища
- 5. Длина 128-bit v1: date+ time + 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.
- 13. The timestamp isa 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. 0011011101000110111 0000000001110 0011011101000110111 0000101011000 00110111010001101110001110010010 0011011101000110111 0010001111000 0011011101000110111 0011000011100 0011011101000110111 0011011101110 0011011101000110111 0100001110100
- 16. Big-endian vs little-endian, потомусекундная фракция попала в начало Отсутствие равномерного распределения из-за особенностей генерации
- 17. Остановка миграции и отказот переноса?
- 18.
- 19.
- 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-таблицы Начинается выборка данных, с регулятором скорости Импорт на destination сервер дампа
- 31. Атомарно создаются триггерана INSERT, UPDATE, DELETE с записью изменений в delta-таблицы Начинается выборка данных, с регулятором скорости Импорт на destination сервер дампа Загрузка данных с delta-таблиц
- 32. Атомарно создаются триггерана INSERT, UPDATE, DELETE с записью изменений в delta-таблицы Начинается выборка данных, с регулятором скорости Импорт на destination сервер дампа Загрузка данных с 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. При этом tablecache lock не снялся!
- 43. Следствие: все запросы вожидании
- 44.
- 45. Замедляться выполнение еще можетиз-за включенного adaptive hash index Scan по buffer pool для чистки adaptive hash index может выполняться долго https://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.
- 55.
- 56. За решение дамбилет
- 57. О том какинвалидировался кэш memcached при добавлении/удалении сервера в пул
- 58. server_id = hash(key)% num_servers hash может быть crc32, fnv, md5, murmur, etc Стандартный алгоритм в Memcache и Memcached:
- 59.
- 60.
- 61.
- 62. При стандартном потоке инвалидируетсяпочти все При consistent hashing инвалидируется только 1/N, где N – количество серверов в пуле
- 63. Как незнание особенностейработы GC у redis обошлось в $50к чистой прибыли
- 64. Response time: mean99th percentile Response time: mean
- 65. Response time: mean99th percentile Response time: mean Response time: 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.
- 73.
- 77. Ошибка в ядреPHP, что привела к даунтайму на несколько часов
- 79. Завис SoapServer партнера Наши PHPскрипты с SoapClient обращались на SoapServer Но не умирали по таймауту!
- 80. Код выглядел корректно, таймауты были: connection_timeout default_socket_timeout Ноstrace показывал, что клиент игнорирует настройки.
- 81. Разработчики забыли включить таймаутдля HTTPS https://bugs.php.net/bug.php?id=48524
- 82. Как поправить тестпотерять 2 миллиона писем
- 84.
- 86.
- 87.
- 88.
- 89. Смена состояния системы приошибке обработки с последующим nack Отсутствие очередности в доставке сообщений Purge очереди Hard reboot rabbitmq Включение auto acknowledgment в коде Факторы потери/порчи данных:
- 90. Как же житьс highload?
- 91. Как же житьс highload? Практически проверять внедряемые решения Думать как изменение может затронуть систему Собирать метрики и правильно анализировать их Инвестировать в знания
- 92.
- 93.