Сальса, румба, капоэйра, яркие костюмы, энергичная бразильская музыка — в SAP Digital Space проходит бразильский карнавал. Продакты, управляющие и директора IT-компаний несколько минут назад слушали как захватывать рынки, строить программу обучения и анализировать данные, и вот они подтанцовывают в такт музыке, фотографируются и улыбаются. Так завершился Product Fest, последняя конференция Онтико в 2019 году. Это значит, что пришло время подвести итоги: осознать, что произошло, посмотреть назад, вспомнить интересные моменты и провести ретроспективу.
Рубрика «highload» - 4
Бразилия, темная магия, Mortal Kombat, Марс и 15000 человек. Итоги года Онтико
2019-12-30 в 10:32, admin, рубрики: devopsconf, frontendconf, highload, inothings++, teamleadconf, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, итоги года 2019, конференции, Новый Год, Разработка веб-сайтов
Как устроен поиск Яндекс.Маркета и что будет, если упадёт один из серверов
2019-11-21 в 9:06, admin, рубрики: highload, балансировка нагрузки, Блог компании Яндекс, микросервисы, надежность, облачные сервисы, Разработка веб-сайтов, Серверная оптимизация, яндексПривет, меня зовут Евгений. Я работаю в инфраструктуре поиска Яндекс.Маркета. Хочу рассказать сообществу Хабра о внутренней кухне Маркета – а рассказать есть что. Прежде всего, как устроен поиск Маркета, процессы и архитектура. Как мы справляемся с внештатными ситуациями: что случится, если упадёт один сервер? А если таких серверов будет 100?
А ещё вы узнаете, как мы внедряем новую функциональность на куче серверов сразу. И как тестируем сложные сервисы прямо в production, не доставляя пользователям никаких неудобств. В общем, как устроен поиск Маркета, чтобы всем было хорошо.
Высокая производительность и нативное партиционирование: Zabbix с поддержкой TimescaleDB
2019-10-14 в 9:36, admin, рубрики: highload, Partitioning, postgres, timescaledb, zabbix, Администрирование баз данных, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, кэширование, Разработка веб-сайтов, хранение данныхZabbix — это система мониторинга. Как и любая другая система, она сталкивается с тремя основными проблемами всех систем мониторинга: сбор и обработка данных, хранение истории, ее очистка.
Этапы получения, обработки и записи данных занимают время. Немного, но для крупной системы это может выливаться в большие задержки. Проблема хранения — это вопрос доступа к данным. Они используются для отчетов, проверок и триггеров. Задержки при доступе к данным также влияют на производительность. Когда БД разрастаются, неактуальные данные приходится удалять. Удаление — это тяжелая операция, которая также съедает часть ресурсов.
Проблемы задержек при сборе и хранении в Zabbix решаются кэшированием: несколько видов кэшей, кэширование в БД. Для решения третьей проблемы кэширование не подходит, поэтому в Zabbix применили TimescaleDB. Об этом расскажет Андрей Гущин — инженер технической поддержки Zabbix SIA. В поддержке Zabbix Андрей больше 6 лет и напрямую сталкивается с производительностью.
Как работает TimescaleDB, какую производительность может дать по сравнению с обычным PostgreSQL? Какую роль играет Zabbix для БД TimescaleDB? Как запустить с нуля и как мигрировать с PostgreSQL и производительность какой конфигурации лучше? Обо всем этом под катом.
Читать полностью »
Безболезненный Fallback Cache на Scala
2019-09-05 в 10:30, admin, рубрики: fallback, highload, scala, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, функциональное программированиеВ крупных или микросервисных архитектурах самый важный сервис не всегда самый производительный и бывает не предназначен для хайлоада. Мы говорим о бэкенде. Он работает медленно — теряет время на обработке данных и ожидании ответа между ним и СУБД, и не масштабируется. Даже если само приложение масштабируется легко, это узкое место не масштабируется совсем. Как эту проблему решить и обеспечить высокую производительность? Как обеспечить ответ системы, когда важные источники информации молчат?
Если ваша архитектура полностью соответствует Reactive-манифесту, составные части приложения неограниченно масштабируются с возрастанием нагрузки независимо друг от друга, и выдерживают падение любого узла, — вы знаете ответ. Но если нет, то Олег Нижников (Odomontois) расскажет, как проблему масштабируемости решили в Тинькофф, построив свой безболезненный Fallback Cache на Scala, не переписывая приложение.
Примечание. В статье будет минимум кода на Scala и максимум общих принципов и идей.
Читать полностью »
LuaVela: реализация Lua 5.1, основанная на LuaJIT 2.0
2019-08-29 в 9:59, admin, рубрики: announce, C, highload, IPONWEB, Lua, luajit, анонс, Блог компании IPONWEB, системное программированиеНекоторое время назад мы анонсировали публичный релиз и открыли под лицензией MIT исходный код LuaVela – реализации Lua 5.1, основанной на LuaJIT 2.0. Мы начали работать над ним в 2015 году, и к началу 2017 года его использовали в более чем 95% проектов компании. Сейчас хочется оглянуться на пройденный путь. Какие обстоятельства подтолкнули нас к разработке собственной реализации языка программирования? С какими проблемами мы столкнулись и как их решали? Чем LuaVela отличается от остальных форков LuaJIT?
Failover: нас губит перфекционизм и… лень
2019-07-19 в 7:12, admin, рубрики: accessibility, diy или сделай сам, failover, highload, ITSumma, uptime, uptimeday, Блог компании ITSumma, доступность, инфраструктура, отказоустойчивость, резервирование, резервное копированиеЛетом традиционно снижается и покупательская активность, и интенсивность изменения инфраструктуры веб-проектов, говорит нам Капитан Очевидность. Просто потому что даже айтишники, случается, ходят в отпуск. И CТО тоже. Тем тяжелее тем, кто остаётся на посту, но сейчас не об этом: возможно, именно поэтому лето — лучший период для того, чтобы не торопясь обдумать существующую схему резервирования и составить план по её улучшению. И в этом вам будет полезен опыт Егора Андреева из AdminDivision, о котором он рассказал на конференции Uptime day.
При строительстве резервных площадок, при резервировании есть несколько ловушек, в которые можно попасть. А попадаться в них совершенно нельзя. И губит нас во всем этом, как и во многом другом, перфекционизм и… лень. Мы пытаемся сделать всё-всё-всё идеально, а идеально делать не нужно! Нужно делать только определённые вещи, но сделать их правильно, довести до конца, чтоб они нормально работали.
Failover — это не какая-то такая весёлая фановая штука «чтоб было»; это вещь, которая должна сделать ровно одно — уменьшить время простоя, чтобы сервис, компания, теряла меньше денег. И во всех методах резервирования я предлагаю думать в следующем контексте: где деньги?
По следам Highload++ Siberia 2019 — 8 задач по Oracle
2019-07-12 в 11:04, admin, рубрики: highload, oracle, smlab, sql, Администрирование баз данных, базы данных, Блог компании Sportmaster Lab, СпортмастерПривет!
24-25 июня в Новосибирске прошла конференция Highload++ Siberia 2019. Наши ребята тоже там были докладом «Контейнерные базы Oracle (CDB/PDB) и их практическое использование для разработки ПО», мы выложим текстовую версию немного позже. Было круто, спасибо olegbunin за организацию, а также всем, кто пришёл.
В этом посте мы хотели бы поделиться с вами задачами, которые были на нашем стенде, чтобы вы могли проверить свои знания в Oracle. Под катом — 8 задач, варианты ответов и объяснение.
Читать полностью »
Анализ производительности запросов в ClickHouse. Доклад Яндекса
2019-07-08 в 13:05, admin, рубрики: big data, clickhouse, highload, open source, perf, performance, базы данных, Блог компании Яндекс, высокая производительность, Серверное администрированиеЧто делать, если ваш запрос к базе выполняется недостаточно быстро? Как узнать, оптимально ли запрос использует вычислительные ресурсы или его можно ускорить? На последней конференции HighLoad++ в Москве я рассказал об интроспекции производительности запросов — и о том, что даёт СУБД ClickHouse, и о возможностях ОС, которые должны быть известны каждому.
Каждый раз, когда я делаю запрос, меня волнует не только результат, но и то, что этот запрос делает. Например, он работает одну секунду. Много это или мало? Я всегда думаю: а почему не полсекунды? Потом что-нибудь оптимизирую, ускоряю, и он работает 10 мс. Обычно я доволен. Но все-таки я стараюсь в этом случае сделать недовольное выражение лица и спросить: «Почему не 5 мс?» Как можно выяснить, на что тратится время при обработке запроса? Можно ли его в принципе ускорить?
Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE
2019-06-29 в 11:16, admin, рубрики: benchmark, highload, postgresql, перевод с английскогоДанная статья является переводом оригинальной статьи Martin Kováčik «PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE» https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах
Перевод
В этом посте я собираюсь показать результаты тестов недавно выпущенного PostgreSQL 10.1. Я проверил БД на этих ОС (все 64-битные):
- Ubuntu 16.04, ядро 4.10.0-38-generic
- openSUSE 42.3, ядро 4.4.87-25-default
- CentOS 7.4, ядро 3.10.0-693.2.2.el7.x86_64
- Debian 9.2, ядро 4.9.0-4-amd64
- FreeBSD 11.1
How to speed up LZ4 decompression in ClickHouse?
2019-06-25 в 14:42, admin, рубрики: bayesian optimization, big data, c++, clickhouse, data compression, databases, highload, lz4, lz77, open source, performance, Блог компании Яндекс, высокая производительностьWhen you run queries in ClickHouse, you might notice that the profiler often shows the LZ_decompress_fast function near the top. What is going on? This question had us wondering how to choose the best compression algorithm.
ClickHouse stores data in compressed form. When running queries, ClickHouse tries to do as little as possible, in order to conserve CPU resources. In many cases, all the potentially time-consuming computations are already well optimized, plus the user wrote a well thought-out query. Then all that's left to do is to perform decompression.
So why does LZ4 decompression becomes a bottleneck? LZ4 seems like an extremely light algorithm: the data decompression rate is usually from 1 to 3 GB/s per processor core, depending on the data. This is much faster than the typical disk subsystem. Moreover, we use all available CPU cores, and decompression scales linearly across all physical cores.
Читать полностью »