Комментарии 20
Время работы системы 1857 дней.
Ммм. Ни устранения уязвимостей, ни обновления прошивок, ни обновления пакетов, потому что судя по статье она заработало и дышать на нее уже все боятся. Докерами то нагрузку с хоста не хост без прерывания не погоняешь, что бы хосты обслужить :) Архитектура отказоустойчивости на уровне хостов как в RAID0.
Приложение 2.
Вот бы кто то пользовался блоками кода и ссылки правильно оформлял
Мониторинг срань. Про бэкапы не слова, хотя бы про базы. Написание терминов меняется по статье, видимо писал не один человек. Оформление на троечку с минусом.
Но за статью спасибо, познавательно в плане маломальски больших нагрузок, хотя отказ от виртуализации явно огромный минус в плане скорости обслуживания/восстановления.
Зато большой плюс в плане производительности.
Большой плюс - это сколько? Быстрее на 5%-10%-30%-100%-200%?
Все 100% настоящих проблем, которые я видел с 1С невозможно было закидать железом, потому что проблемы были с кодом 1С, и собственно его правкой проблемы с производительностью и устраняли.
Я постоянно вижу, что специалисты 1С и внедренцы 1С закатывают глаза и требуют 100500 ядер и памяти, и они даже уже узнали что такое NVMe и его тоже теперь требуют, но в итоге все это спокойно взлетает внутри виртуализации, прекрасно обслуживается и автоматизируется.
Вот бы увидеть сравнение на большой базе и импакт от виртуализации в условных vmware/hyper-v/kvm хоть разок, а то все говорят, но никто показать не может.
Я постоянно вижу, что специалисты 1С и внедренцы 1С закатывают глаза и требуют 100500 ядер и памяти
Мне вот тоже всегда интересно, чем им помогут ядра и память, когда из-за ошибки статистики PostgreSQL попадает в Nested Loop Left Join с Seq Scan (да пусть даже и индекс скан). Как в скрине ниже. И там дальше сложность 4210*55582. Будет там записей в 10 раз больше, и даже на суперкомпьютере не выполнится этот запрос никогда.
Очень сильно сомневаюсь в таком аптайме, за такой период платформа ниразу не обновлялась? И не выключались ээ на заводе?
В ваших планах, я вижу как минимум одну странность :
Планируемое количество записей - 1, а реальное - 4210. Естественно, при таких раскладах начинают выбираться не те алгоритмы для дальнейшей обработки (типа Nested Loop Left Join).
Тут или 1С не делает ANALYZE временных таблиц после записи в них, или просто так получается из-за статистики по колонкам. Но в целом сам запрос, который сформировал 1С - очень странный. При таких запросах на нормальных объемах данных там все будет очень сильно тормозить именно из-за нерелевантной статистики. Возможно такие запросы и прокатывают в MSSQL (возможно там перепланирование есть - я не сильно в MSSQL разбираюсь), но вот в PostgreSQL так делать не стоит.
Не спец в бд, но 1с очень любит такие запросы. Только 1 и 4210 это ещё по божески, чаще вижу 100 и 1500000 например. Это я про ерп и постгрес.
1) У нас начались проблемы при приближении к 50 пользователям и мы купили серверов на полтеррайбайта ОЗУ, чуть ли не топовыми дисками и процессоров там стока, что хватит на каждого пользователя из этих 50 по 1 ядру в любую секунду. Черт побери, вот это запас так запас!
2) Но и этого нам не хватило, поэтому часть конфигураций мы каждое обновление на протяжении нескольких лет меняли под себя (а там обновления чуть ли не каждые 2 недели выпускают. ну всего то 24 исправления в год, фигня какая). Некоторые проблемы аж совместно с вендором пришлось решать, потому что ошибка платформы (даже страшно представить, сколько времени на это ушло). Для некоторых проблем нам пришлось обзавестись хорошим DBA и переписать часть ерп под себя.
— Все это дополнительные проблемы при переходе на pgsql.
Вывод: PGSQL не несет существенных рисков, можно работать. Ничего себе. Может я ошибаюсь, но mssql на 50 пользователей обошелся бы в районе 400к. А проблем выше описано ничуть не на меньшую сумму, причем многие из них не решаются однократным вложением.
Сервер под Postgres SQL
Этот сервер также разбит на docker'ы.
Дальше читать нет необходимости. Но я себя пересилил. Дошёл до:
Время работы системы 1857 дней.
Понимание необходимости обновления (первый комментарий, однако) отсутствует, как класс. Помимо уже сказанного явно отсутствует какая-нибудь отказоустойчивость, т.е. накрылась железка, производство встало. Всё, дальше уже просто неинтересно.
Вот зря вы БД в докеры запихнули... И тема с разделами и дисками именно под БД не раскрыта, а это 90% производительности.
Как по мне, постгрю стоило разместить без докеров, нативно. И если уж так хочется - поднять несколько кластеров. Но обязательно разнести WAL и БД по дискам, тем более с системой.
Но обязательно разнести WAL и БД по дискам, тем более с системой.
зачем этот рецепт из эпохи hdd для nvme с plp?
изучите как работает WAL для движка постгри, тогда поймете что это актуально даже для рам дисков. В закладках лежит вот эта статья с хабра, и она по прежнему торт https://habr.com/ru/post/414269/ (постгря в ряде мест похожа по работе с MS SQL)
гхм, да, я немного знаю как работает wal у pg. и у других БД тоже, где-то документацию читал, где-то исходники.
а вы представляете порядок цифр задержек/iops при разумных глубинах очереди у современных накопителей?
запускаем родной постгресовский pg_test_fsync
root@debian:/mnt# /usr/lib/postgresql/13/bin/pg_test_fsync
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 56557.921 ops/sec 18 usecs/op
fdatasync 53466.818 ops/sec 19 usecs/op
fsync 53697.207 ops/sec 19 usecs/op
fsync_writethrough n/a
open_sync 57042.429 ops/sec 18 usecs/op
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 32122.388 ops/sec 31 usecs/op
fdatasync 37222.259 ops/sec 27 usecs/op
fsync 42163.907 ops/sec 24 usecs/op
fsync_writethrough n/a
open_sync 32224.026 ops/sec 31 usecs/op
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
1 * 16kB open_sync write 47167.621 ops/sec 21 usecs/op
2 * 8kB open_sync writes 32225.729 ops/sec 31 usecs/op
4 * 4kB open_sync writes 18169.764 ops/sec 55 usecs/op
8 * 2kB open_sync writes pg_test_fsync: error: write failed: Invalid argumentзапоминаем.
теперь запускаем запись в один поток
fio -ioengine=libaio -sync=0 -direct=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=300 -filename=/dev/nvme0n1p2 -numjobs=1и параллельно опять pg_test_fsync
root@debian:/mnt# /usr/lib/postgresql/13/bin/pg_test_fsync
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 58961.447 ops/sec 17 usecs/op
fdatasync 55535.067 ops/sec 18 usecs/op
fsync 54103.027 ops/sec 18 usecs/op
fsync_writethrough n/a
open_sync 58130.756 ops/sec 17 usecs/op
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 31620.204 ops/sec 32 usecs/op
fdatasync 42161.690 ops/sec 24 usecs/op
fsync 42438.145 ops/sec 24 usecs/op
fsync_writethrough n/a
open_sync 31168.113 ops/sec 32 usecs/op
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
1 * 16kB open_sync write 46772.167 ops/sec 21 usecs/op
2 * 8kB open_sync writes 31065.014 ops/sec 32 usecs/op
4 * 4kB open_sync writes 17256.682 ops/sec 58 usecs/op
8 * 2kB open_sync writes pg_test_fsync: error: write failed: Invalid argumentой, ничего не изменилось, разброс между цифрами в пределах статистической погрешности.
запускаем тест чтения
root@debian:~# fio -ioengine=libaio -sync=0 -direct=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=300 -filename=/dev/nvme0n1p2 -numjobs=1и снова параллельно pg_test_fsync
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 55772.967 ops/sec 18 usecs/op
fdatasync 53240.283 ops/sec 19 usecs/op
fsync 53314.293 ops/sec 19 usecs/op
fsync_writethrough n/a
open_sync 56384.710 ops/sec 18 usecs/op
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 31189.625 ops/sec 32 usecs/op
fdatasync 40931.302 ops/sec 24 usecs/op
fsync 40972.844 ops/sec 24 usecs/op
fsync_writethrough n/a
open_sync 31284.131 ops/sec 32 usecs/op
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
1 * 16kB open_sync write 45541.045 ops/sec 22 usecs/op
2 * 8kB open_sync writes 31411.537 ops/sec 32 usecs/op
4 * 4kB open_sync writes 17673.122 ops/sec 57 usecs/op
8 * 2kB open_sync writes pg_test_fsync: error: write failed: Invalid argumentснова те же цифры
ладно, это недостаточно брутально, запустим смешанную нагрузку r/w с qd=4
root@debian:~# fio -ioengine=libaio -sync=0 -direct=1 -name=test -bs=4k -iodepth=4 -rw=randrw -runtime=300 -filename=/dev/nvme0n1p2 -numjobs=1root@debian:/mnt# /usr/lib/postgresql/13/bin/pg_test_fsync
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 57342.285 ops/sec 17 usecs/op
fdatasync 54096.805 ops/sec 18 usecs/op
fsync 53349.472 ops/sec 19 usecs/op
fsync_writethrough n/a
open_sync 56312.876 ops/sec 18 usecs/op
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
open_datasync 31359.312 ops/sec 32 usecs/op
fdatasync 42139.124 ops/sec 24 usecs/op
fsync 41731.166 ops/sec 24 usecs/op
fsync_writethrough n/a
open_sync 31095.245 ops/sec 32 usecs/op
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
1 * 16kB open_sync write 46177.769 ops/sec 22 usecs/op
2 * 8kB open_sync writes 30933.351 ops/sec 32 usecs/op
4 * 4kB open_sync writes 17237.141 ops/sec 58 usecs/op
8 * 2kB open_sync writes pg_test_fsync: error: write failed: Invalid argumentвы видите измеримое влияние нагрузки на ssd на задержки синхронной записи? я — нет.
В прошлый раз читал статью с компа, офопмлено было плохо, код нечитабелен. А сейчас вот открыл с телефона - все стало крксиво, ну кроме кода. При этом, как я понял, автор со статьей ничего не делал. Так что кому не нравится - читайте эту статью с телефона))))
ЗЫ: проголосовать не могу - был замечен в политических диспутах)))
"Кластер" из трех контейнеров с сервером 1С на одном физическом хосте - это сильно!
Я бы еще предложил таким же образом "кластер" Postgres на соседнем хосте поднять - чтобы интереснее было )
А если по делу - то вопрос: как сервер 1С в контейнерах относится к одному единственному аппаратному ключу?
Ну и, я так полагаю, с одной единственной программной лицензией тут ловить, скорей всего, будет нечего, т.к. непонятно, как её "скормить" всем контейнерам, и чтобы они не начали "возмущаться" на тему несовпадения конфигурации системы.
я давно уже ушел из темы 1с, но уже лет 10 назад они активно отказывались продавать физические. Переводили всех на программные лицензии (которые дико глючили). Единственный способ получить, это иметь легаси лицензии (типа 8.1)
Физической было пофиг сколько кластеров на сервере, видимо это и напрягало производителя.
По статистике на разворачивание сервера Linux уходит примерно 1,5 часа.
Во всех системах виртуализации есть такая волшебная штука, как шаблоны ВМ. В зависимости от виртуализации и аппаратной платформы, разворачивание сервера из шаблона занимает от нескольких секунд, до 5-10 минут на старом железе, если нужно именно скопировать весь диск. Плюс замена hostname и IP, если не вшито в мастер клонирования из шаблона. Руками ещё 1-2 минуты, ansible чуть меньше.
Как уже ранее написали коллеги, разница между докером и виртуалками незначительная. А с учётом 256 памяти и 24 полноценных ядра, обслуживание гостевых ОС мне вообще кажется меньше, чем погрешность измерений производительности данного сервера. Вопрос к автору: делали ли сравнения, если да, можно результаты?
Опыт работы «1С:ERP» в ландшафте Linux + PostgreSQL – 7 лет