Дальше вжжух вжжух магия и в бд конечно меньше. На моей памяти 20 тыс записей в секунду

Потом верноятно подросло

/dev/null as a service

Но было давно. Память может подводить. Сразу говорю, цифра очень вроде. .

Дальше вжжух вжжух магия и в бд конечно меньше. На моей памяти 20 тыс записей в секунду

Очень хорошие показатели, а какие ттх у сервака?

IBM 3650 m2 в топе (или как то так, если правильно помню)

20к в секунду это прям очень мало

Не для mysql

А для time series

И файлы бд на сторадже хитачи. Толи флеш толи шпинделя. Не помню

А для time series

Конечно. Но тут выше была дискуссия почему мускул и заббикс. Нам так вышло дешевле и быстрее. А платил бизнес. Он и музыку заказывал )

Конечно. Но тут выше была дискуссия почему мускул и заббикс. Нам так вышло дешевле и быстрее. А платил бизнес. Он и музыку заказывал )

Да я читал, да

Конечно. Но тут выше была дискуссия почему мускул и заббикс. Нам так вышло дешевле и быстрее. А платил бизнес. Он и музыку заказывал )

Просто на входе 1 млн и кажется Вау

А когда понимаешь что хранится 20к это уже так себе

У нас просто на хранилищах вот вчера был новый рекорд - 13.7 млн в секунду на 8 часов подряд

20к.

Та отож. Что прицепились все к этим цифрам. Какой то промежуточный параметр. Не имеющий прямого отношения к оказываемому сервису.

Ооооок.

Это потолок заббикса да

Вот и начинается реальные цифры заббикса

Это потолок заббикса да

Это было когда было 30℅ нагрузки. И заббикс 2.4 умер. И не по причине работы с бд ))

Да

И это правда

Это же заббикс

А по причине проблем с внутренними процессами. Это исправили за неделю силами суппорта. И поехали дальше нагружать

И получается 60к в секунду

На версии 3 все прекрасно с той нагрузкой что я описывал

Ну пусть 100к

Та отож. Что прицепились все к этим цифрам. Какой то промежуточный параметр. Не имеющий прямого отношения к оказываемому сервису.

Так они имеют.

Детсад для тайм сериес

И получается 60к в секунду

А это важно? 60к записей или 59к?

Мы стараемся не агрегировать данные

Записей в базу

Потому что люди так могут сами при просмотре выбирать нужный уровень детализации

Или может 120к?

Потому что люди так могут сами при просмотре выбирать нужный уровень детализации

У нас было 60 вроде детально

Далее часовая агрегация

Но могу и ошибаться

60 дней

Так они имеют.

Имеет значение сколько система сожрет на входе

А не сколько там у нее внутри операций с бд

а?

Вот когда клиенту надо передавать метрики в систему мониторинга. Ему же говорят мы можем переварить 5М метрик. И не важно что бд может переварить 15м. Важно что сервис в целом может переварить.

м это что?)

милиметрики?)

Я не знаю скока максимум может заббикс. Или мускул. Мне это не очень интересно. А вот закрыть потребность клиента комплексно. Это мне интересно. Но тут же щас скажут что я не технарь )))

5м или 15м это в каких единицах?

Миллионы

У нас было 60 вроде детально

Я про другое. Вы вот магию делаете - это видимо фильтрация и преаггрегация

И желательно в долларах

То есть вы что то там считаете по ним и записываете результат расчетов, так?

Я про другое. Вы вот магию делаете - это видимо фильтрация и преаггрегация

Да. Заббикс что то агрегирует. Что то пишет пакетно в базу а не каждую метрику отдельной транзакцией. Имеет кеш неслабый в памяти. И много операций делает с метриками в нем

То есть вы что то там считаете по ним и записываете результат расчетов, так?

Отчасти так.

5м или 15м это в каких единицах?

А вам в каких надо?

Имеет значение сколько система сожрет на входе

Надо делить на то что пишется сырым

А что агрегировать

а у меня не заббикс

Надо делить на то что пишется сырым

Ну да, в процессе разработки архитектуры это важно понимать

а у меня не заббикс

Поздравляю )

Ну да, в процессе разработки архитектуры это важно понимать

Это влияет на то что из системы можно получить

Конечно

Заббикс не система для построения отчетов потом. Это система онлайн мониторинга. С отчетами у нее тухло

Потому тут это опять же на этапе проработки архитектуры решения рассматривается.

Плюс если надо работать с историей плотно - можно читать с реплики. На которой нагрузка значительно меньше

Это мне кажется всё уже особенности конкретного решения

ERROR: S client not available

А. Ок

Тоесть таки нагрузки многим меньше. Топология дб прям слабая

Мой ступор на 1.3м в секунду был зря.

Вот когда клиенту надо передавать метрики в систему мониторинга. Ему же говорят мы можем переварить 5М метрик. И не важно что бд может переварить 15м. Важно что сервис в целом может переварить.

M - миллионов или метрик?

Тоесть снова адепт заббикса со стороны 'бизнеса'

Тоесть таки нагрузки многим меньше. Топология дб прям слабая

Нагрузки на что?

M - миллионов или метрик?

Миллионов метрик

Тоесть снова адепт заббикса со стороны 'бизнеса'

Ага. Потому что я работаю чтобы бизнес был доволен. А не наоборот. Вроде же очевидно.

Миллионов метрик

И каждая сколько заптсывает в дб?

В одну ноду?

И каждая сколько заптсывает в дб?

Да откуда я знаю.

Я ж привел абстрактный пример

А скрины можно? И конфиги, хочу так же. А версия дб какая?

А скрины можно? И конфиги, хочу так же. А версия дб какая?

Чего скрины и конфиги?

Я ж привел абстрактный пример

Мопед не мой. Ок

?

У KOT много опыта в тюнинге муськи профессиональный интерес

У KOT много опыта в тюнинге муськи профессиональный интерес

Конфигурация мускула можно

У KOT много опыта в тюнинге муськи профессиональный интерес

Ммммммм

@Kote_deWoland есть опыт в работе мускула с FusionIO?

Николай Самосват: Кто нибудь использует MySQL на fusionIO: как можно убедиться, что atomicwrite включён, а doublewrite выключен? Версия perсona 5.7 - в доке нашёл что типа мускул сам определяет что живет на фьюжене.. прям магия

Ага. Потому что я работаю чтобы бизнес был доволен. А не наоборот. Вроде же очевидно.

А мы для чего работаем?

А мы для чего работаем?

я так пишу не потому что думаю будто все тут не для того чего надо работают :) А потому что вижу, как упоминанеие целей бизнеса вызывет "икоту" у некоторых :) Что меня искренне удивляет.

Хорошо, что не стал читать вас днем, а оставил под вечернее пиво

Цели бизнеса? Икоту? Николай вы бизнесу продали изнутри не оптимальное решение. Вопрос в этом

@Kote_deWoland конфиг текущего мускула: # The Percona Server 5.7 configuration file. [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /fusion/mysql tmpdir = /fusion/tmp lc-messages-dir = /usr/share/mysql explicit_defaults_for_timestamp bind-address = 127.0.0.1 sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_ALL_TABLES symbolic-links=0 slow-query-log = 1 slow-query-log-file = /var/log/mysql/slow_query.log long_query_time = 3 query_cache_size=0 query_cache_type=0 tmp_table_size = 256M max_allowed_packet=128M default_password_lifetime=0 event_scheduler = off innodb_flush_method = O_DIRECT_NO_FSYNC innodb_file_format = Barracuda innodb_file_per_table = 1 innodb_buffer_pool_size=80G innodb_page_cleaners = 16 innodb_buffer_pool_instances = 16 innodb_flush_log_at_trx_commit = 0 innodb_io_capacity=55000 innodb_io_capacity_max=60000 innodb_read_io_threads=16 innodb_write_io_threads=16 innodb_log_buffer_size=1G innodb_doublewrite=0 innodb_log_write_ahead_size=4096 innodb_log_file_size=128M

А ещё вместе того чтобы признать что решение технически не оптимально вы его защищаете

Цели бизнеса? Икоту? Николай вы бизнесу продали изнутри не оптимальное решение. Вопрос в этом

в чем его неоптимальность?

Технически слабое.

Один из моих бывших руководителй на мои слова типа Слабое Сильное Мало Много Долго Быстро говорил: Эти слова ругательные. И их при нем употреблять ненадо. И был прав как мне кажется :)

Технически слабое.

скажите какие были поставлены передо мной задачи и цели?

Нет не скажу. Скажу что решение не огонь.