ВНИМАНИЕ этот комментарий не ради холивара. Я тут рассказываю свои собственные ощущения от glitchtip, ничего не постулирую, никого не обвиняю, на прописные истины покушаться не планирую.
Поднял glitchtip из docker-compose по ссылке в статье, создал проект и послал пару ивентов.
Про конфигурацию приложения. Мы используем Sentry 9.1.2, менять в конфиге не пришлось ничего кроме SENTRY_DSN. Очень удобно.
Работает glitchtip действительно очень быстро.
Но вот в таблице сравнения возможностей имхо glitchtip приукрасили. Кроме отсутствия дашбордов и трендов (честно не знаю что за тренды в сентри), сильно не хватает:
автодополнения при поиске происшествий;
возможность смержить две проблемы друг с другом -- иногда бывает что сентри не смогает понять, что два сообщения в логах -- это одно и то же событие, и тогда очень удобно их объединить. В glitchip кнопочки Merge я не нашёл вообще, хочется верить что glitchtip никогда не ошибается;
возможность создать пользователя без почты -- в сентри можно кинуть человеку ссылку для создания пользователя, нужно для деплоя без конфигурации smtp. Как в glitchip создать пользователя без отправки ему писем я не нашёл; без почты можно создать пользователя из командной строки, но там нельзя передать пароль через переменную окружения или ещё как -- только вводить вручную что тоже минус.
гистограмм про количество ивентов за последние 24 часа и 30 дней -- в сентри очень удобно видеть, когда ивенты появились и когда прекратились;
комментариев под проблемами -- в сентри прежде чем игнорить или назначить на кого-то проблему, я пишу в комментарии контекст/добавляю ссылку на MR или ещё что-нибудь
возможности назначить на кого-нибудь проблему -- мб решается созданием тасок для каждой проблемы в джире или другом таск-трекере, но без комментариев опять же этого будет нехватать.
Спасибо за статью. С интересом смотрю на clickhouse, планирую попробовать на будущих проектах.
По интеграции с mysql вопрос. В примере в статье даже после фикса проблемы с регистрами в именах, значения столбца count в ответах mysql и clickhouse различаются: во всех строках кроме NULL значения clickhouse чуть меньше, чем mysql. Он выбрасывает какие-то данные? Или просто запросы для статьи делали на живых данных в разное время?
для сравнения чтобы не скролить
clickhouse-local — выглядит шикарно. Но и он дал результаты, отличные от пайплайна grep+sed+sort.
Уверен, что ответ будет положительным, но обязан спросить. Вы ведь убедились, что THB отключены? На только что перезагруженной машине, где запущена только база (которая аллоцирует память кусками одного размера) — разницы с большими страницами почти не будет, так как не будет фрагментации. В ситуации, когда таблица почти целиком лежит в кешах, и во время запросов псевдо-большие страницы не аллоцируются, обслуживание TLB может не повлиять на время тестовых запросов.
Имел в виду THP (Transparent Huge Pages). Первый раз опечатался в одной букве, еще простительно. А вот TLB вместо THP — это уже на грани фола.
Спасибо за статью, было приятно почитать. Но есть пара узких моментов (как всегда со статьями про бенчмарки).
Создаю одну таблицу, размер которой больше ОЗУ сервера, и индекс к этой таблице, который занимает где-то 10% от размера таблицы
а в самом скрипте:
— Размер таблицы, которую нужно создать. Подбирается методом проб и ошибок так, чтобы таблица имела размер, равный ОЗУ.
\set table_size 75000000
я не придираюсь, но это все-таки важный момент. Таблица помещается в память или же нет? Можно было бы заодно проверить и вариант, когда таблица и индекс полностью помещаются в память.
select count(data) from random;
Меня интересует момент про SeqScan (поиск по таблице без индекса). Запрос select count(*) ... вынуждает постгрес выгружать всю таблицу в память. Мы приходим к ситуации, когда все строки таблицы читаются с диска с одинаковой частотой. Это не типичная ситуация для кешей, и проверять их эффективность в такой ситуации может быть не лучшей идеей. Все-таки кеши рассчитаны на ускорение запросов к горячим данным, а не ко всем вообще.
Вы учитывали использование постгресом кольцевых буферов для таких запросов? К сожалению, я в постгресе не эксперт, знаю об этом крайне мало.
О внутренностях системного кеша знаю еще меньше, так что не буду даже загадывать, есть ли подобные вещи там.
Когда я тестировал два года назад на CentOS 7 и PostgreSQL 10, кеш файловой системы работал примерно с такой же скоростью, что и кеш PostgreSQL без HugePages, а добавление HugePages давало значимый выигрыш над кешем файловой системы. Из чего я могу сделать вывод, что за последние годы Linux научился гораздо эффективнее использовать свой файловый кеш.
Уверен, что ответ будет положительным, но обязан спросить. Вы ведь убедились, что THB отключены? На только что перезагруженной машине, где запущена только база (которая аллоцирует память кусками одного размера) — разницы с большими страницами почти не будет, так как не будет фрагментации. В ситуации, когда таблица почти целиком лежит в кешах, и во время запросов псевдо-большие страницы не аллоцируются, обслуживание TLB может не повлиять на время тестовых запросов.
По поводу невозможности выделения больших страниц на давно работающей машине. Под большие страницы выделяется только свободная память. Память, уже занятая файловым кешем, не освобождается. Вместо перезагрузки можно сбросить системный кеш:
sysctl vm.drop_caches=1
или
echo 1 > /proc/sys/vm/drop_caches
Еще момент. Графики показывают, что использование больших страниц не дает ускорения (а где дает, там ускорение незначительно). Что наводит меня на мысль, что что-то здесь не так. Возможно, дело в том, что в ситуациях, когда вы читаете 16Гб случайных данных (не важно, в страницах 4кб или 2Мб), TLB в любом случае переполняется множество раз, и выйгрыша в больших страницы нет. Но в этом вопросе я тоже не особо разбираюсь, может прокомментирует кто из знатоков.
Интересно, что генетическая информация может передаваться не только от родителя к ребенку, но и в иных направлениях. Как то: конъюгация у бактерий, которые просто передают своим соседям часть своего ДНК, либо более интересное явление горизонтального переноса генетической информации (это скорее про вирусы).
Специально для Вас нагуглил почитать на N+1: Поверх барьеров.
Я понимаю, что Вы и так знаете то, что я опишу ниже, но здесь — самое место для моего комментария.
+1 Гб — это магическое число, взятое с потолка.
Мы вместо Xms/Xmx используем -XX:MaxRAM=2g, тогда JVM не вылазит за границы, очерченные лимитами контейнера. В этом случае куча (heap) приложения займет примерно 1.2g (кажется, на хип отводится 60% от MaxRAM).
Получается примерно то же самое, что определить Xmx=1g, а в лимите прописать 2g (+1Gb как рекоммендует автор), но уже без магии.
inferrna предлагает недостающий 0.01 перекинуть с 1.09 на 1.11.
Тогда каждый получит ровно то, что просил.
А покупатель заплатит за все 1.10, несмотря на то, что часть заявки закрыта лотами по 1.11, а часть — по 1.09
Однако мне кажется, покупатель был бы не рад такому варианту. Ему лучше сейчас закрыть по 1.10 + 1.09 (сколько можно), а потом дождаться, пока кто-то закроет остатки его заявки по 1.10.
Отдельное спасибо за перевод статей от Gwern. С удовольствием читаю его статьи (читаю в оригинале на его сайте, но эту пропустил) и, по-возможности, делюсь с окружающими.
UPD: изначально комментарий выглядел иначе, но я вовремя сообразил, что это перевод статьи.
Спасибо за исчерпывающее руководство по инструменту.
Почитать и поэкспериментирвать было очень интересно, но в рабочих проектах постараюсь не использовать. Слишком много требуется ручной работы с гитом, GUI (напримет, плагин от JetBrains) эти функции скорее всего не поддерживает, а поломать что-то неосторожным движением кажется весьма вероятным.
На моей версии git 2.25.1 из стандартной поставки ubuntu 20.04 ppa комманда git-subtree исключена из автодополнения, что привносит свои неудобства; к тому же у меня нет опции --list
$ git version
git version 2.25.1
$ git subtree --help
usage: git subtree add --prefix=<prefix> <commit>
or: git subtree add --prefix=<prefix> <repository> <ref>
or: git subtree merge --prefix=<prefix> <commit>
or: git subtree pull --prefix=<prefix> <repository> <ref>
or: git subtree push --prefix=<prefix> <repository> <ref>
or: git subtree split --prefix=<prefix> <commit>
-h, --help show the help
-q quiet
-d show debug messages
-P, --prefix ... the name of the subdir to split out
-m, --message ... use the given message as the commit message for the merge commit
options for 'split'
--annotate ... add a prefix to commit message of new commits
-b, --branch ... create a new branch from the split subtree
--ignore-joins ignore prior --rejoin commits
--onto ... try connecting new tree to an existing one
--rejoin merge the new branch back into HEAD
options for 'add', 'merge', and 'pull'
--squash merge subtree changes as a single commit
Прочитал статью, решил попробовать.
ВНИМАНИЕ этот комментарий не ради холивара. Я тут рассказываю свои собственные ощущения от glitchtip, ничего не постулирую, никого не обвиняю, на прописные истины покушаться не планирую.
Поднял glitchtip из docker-compose по ссылке в статье, создал проект и послал пару ивентов.
Про конфигурацию приложения. Мы используем Sentry 9.1.2, менять в конфиге не пришлось ничего кроме SENTRY_DSN. Очень удобно.
Работает glitchtip действительно очень быстро.
Но вот в таблице сравнения возможностей имхо glitchtip приукрасили. Кроме отсутствия дашбордов и трендов (честно не знаю что за тренды в сентри), сильно не хватает:
автодополнения при поиске происшествий;
возможность смержить две проблемы друг с другом -- иногда бывает что сентри не смогает понять, что два сообщения в логах -- это одно и то же событие, и тогда очень удобно их объединить. В glitchip кнопочки
Mergeя не нашёл вообще, хочется верить что glitchtip никогда не ошибается;возможность создать пользователя без почты -- в сентри можно кинуть человеку ссылку для создания пользователя, нужно для деплоя без конфигурации smtp. Как в glitchip создать пользователя без отправки ему писем я не нашёл; без почты можно создать пользователя из командной строки, но там нельзя передать пароль через переменную окружения или ещё как -- только вводить вручную что тоже минус.
гистограмм про количество ивентов за последние 24 часа и 30 дней -- в сентри очень удобно видеть, когда ивенты появились и когда прекратились;
комментариев под проблемами -- в сентри прежде чем игнорить или назначить на кого-то проблему, я пишу в комментарии контекст/добавляю ссылку на MR или ещё что-нибудь
возможности назначить на кого-нибудь проблему -- мб решается созданием тасок для каждой проблемы в джире или другом таск-трекере, но без комментариев опять же этого будет нехватать.
Спасибо за развернутый ответ.
Еще одно напоминание, что из коробки ничто не работает — всегда нужно разбираться с деталями.
Спасибо за статью. С интересом смотрю на clickhouse, планирую попробовать на будущих проектах.
По интеграции с mysql вопрос. В примере в статье даже после фикса проблемы с регистрами в именах, значения столбца count в ответах mysql и clickhouse различаются: во всех строках кроме NULL значения clickhouse чуть меньше, чем mysql. Он выбрасывает какие-то данные? Или просто запросы для статьи делали на живых данных в разное время?
clickhouse-local — выглядит шикарно. Но и он дал результаты, отличные от пайплайна grep+sed+sort.
Почему не пойти по пути KubeDashboard и не использовать токен/сертификат пользователя?
т.е. я прихожу в Web-GUI и ввожу там вместо логин/пароля свой токен/сертификат.
Kube-Helper в свою очередь не использует примонтированный токен от сервис-аккаунта, а для всех запросов использует мой токен/сертификат.
Имел в виду THP (Transparent Huge Pages). Первый раз опечатался в одной букве, еще простительно. А вот TLB вместо THP — это уже на грани фола.
del
Скрипт не мой, где взял — не помню. Но огромное человеческое спасибо автору за это.
Для использования в
.bashrcнужно его "засорсить":source colors.sh.Спасибо за статью, было приятно почитать. Но есть пара узких моментов (как всегда со статьями про бенчмарки).
а в самом скрипте:
я не придираюсь, но это все-таки важный момент. Таблица помещается в память или же нет? Можно было бы заодно проверить и вариант, когда таблица и индекс полностью помещаются в память.
Меня интересует момент про SeqScan (поиск по таблице без индекса). Запрос
select count(*) ...вынуждает постгрес выгружать всю таблицу в память. Мы приходим к ситуации, когда все строки таблицы читаются с диска с одинаковой частотой. Это не типичная ситуация для кешей, и проверять их эффективность в такой ситуации может быть не лучшей идеей. Все-таки кеши рассчитаны на ускорение запросов к горячим данным, а не ко всем вообще.Вы учитывали использование постгресом кольцевых буферов для таких запросов? К сожалению, я в постгресе не эксперт, знаю об этом крайне мало.
О внутренностях системного кеша знаю еще меньше, так что не буду даже загадывать, есть ли подобные вещи там.
Уверен, что ответ будет положительным, но обязан спросить. Вы ведь убедились, что THB отключены? На только что перезагруженной машине, где запущена только база (которая аллоцирует память кусками одного размера) — разницы с большими страницами почти не будет, так как не будет фрагментации. В ситуации, когда таблица почти целиком лежит в кешах, и во время запросов псевдо-большие страницы не аллоцируются, обслуживание TLB может не повлиять на время тестовых запросов.
По поводу невозможности выделения больших страниц на давно работающей машине. Под большие страницы выделяется только свободная память. Память, уже занятая файловым кешем, не освобождается. Вместо перезагрузки можно сбросить системный кеш:
или
Еще момент. Графики показывают, что использование больших страниц не дает ускорения (а где дает, там ускорение незначительно). Что наводит меня на мысль, что что-то здесь не так. Возможно, дело в том, что в ситуациях, когда вы читаете 16Гб случайных данных (не важно, в страницах 4кб или 2Мб), TLB в любом случае переполняется множество раз, и выйгрыша в больших страницы нет. Но в этом вопросе я тоже не особо разбираюсь, может прокомментирует кто из знатоков.
Интересно, что генетическая информация может передаваться не только от родителя к ребенку, но и в иных направлениях. Как то: конъюгация у бактерий, которые просто передают своим соседям часть своего ДНК, либо более интересное явление горизонтального переноса генетической информации (это скорее про вирусы).
Специально для Вас нагуглил почитать на N+1: Поверх барьеров.
А можете поделиться ссылкой, чтобы не быть голословным?
Очень интересно, что они и на что подменяют в паролях. И что при этом ломается.
В каких?
Я понимаю, что Вы и так знаете то, что я опишу ниже, но здесь — самое место для моего комментария.
+1 Гб — это магическое число, взятое с потолка.
Мы вместо Xms/Xmx используем
-XX:MaxRAM=2g, тогда JVM не вылазит за границы, очерченные лимитами контейнера. В этом случае куча (heap) приложения займет примерно 1.2g (кажется, на хип отводится 60% от MaxRAM).Получается примерно то же самое, что определить Xmx=1g, а в лимите прописать 2g (+1Gb как рекоммендует автор), но уже без магии.
Зачем выбирать такой режим? Другими словами, какой смысл выбирать этот режим, кроме переноса в другую SQL базу (например, mySql)?
Если нужен быстрый бэкап/быстрое восстановление, почему не pg_basebackup?
inferrna предлагает недостающий 0.01 перекинуть с 1.09 на 1.11.
Тогда каждый получит ровно то, что просил.
А покупатель заплатит за все 1.10, несмотря на то, что часть заявки закрыта лотами по 1.11, а часть — по 1.09
Однако мне кажется, покупатель был бы не рад такому варианту. Ему лучше сейчас закрыть по 1.10 + 1.09 (сколько можно), а потом дождаться, пока кто-то закроет остатки его заявки по 1.10.
Иногда нужно отвечать "потому что по-другому никак": антревольт
Поправьте меня, если я ошибаюсь, но разве в DevOps уже не содержится Developer? Зачем куда-то ходить и кому-то говорить?
Если Вы добавляете памяти в базу, а разработчик дергает в ней
, то почему это зовется DevOps?
В соседней ветке ругают, но по-мне так для шелл-скрипта нормальное решение.
Единственная проблема — неочевидное для человека, который впервые такое встречает (как пример — для меня).
Тем более, остальные части скрипта выглядят понятными (множество сообщений об ошибках добавляют ясности).
Отдельное спасибо за перевод статей от Gwern. С удовольствием читаю его статьи (читаю в оригинале на его сайте, но эту пропустил) и, по-возможности, делюсь с окружающими.
UPD: изначально комментарий выглядел иначе, но я вовремя сообразил, что это перевод статьи.
Спасибо за исчерпывающее руководство по инструменту.
Почитать и поэкспериментирвать было очень интересно, но в рабочих проектах постараюсь не использовать. Слишком много требуется ручной работы с гитом, GUI (напримет, плагин от JetBrains) эти функции скорее всего не поддерживает, а поломать что-то неосторожным движением кажется весьма вероятным.
На моей версии git
2.25.1из стандартной поставки ubuntu 20.04 ppa комманда git-subtree исключена из автодополнения, что привносит свои неудобства; к тому же у меня нет опции--listНет. Хотя согласен, что это было бы логичным продолжением статьи.