Size: a a a

PostgreSQL + 1C + Linux

2021 April 13

SP

Super Padre in PostgreSQL + 1C + Linux
Всегда имеет смысл напоминать заказчикам про принцип "скупой платит дважды"
Иногда отрезвляет от поспешных попыток купить самый дешман
источник

AT

Alex Tkachuk in PostgreSQL + 1C + Linux
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
контроллер один. На этом сходство заканчивается
источник

{o

{o o} in PostgreSQL + 1C + Linux
Интересно как вообще решается вопрос с Write Back при использовании nvme.
Быстрая запись конечно хорошо, но в целом флеш это же не про быструю запись, а скорее про быструю случайную, и быстрое чтение (любое).
Особенно с TLC и QLC
источник

{o

{o o} in PostgreSQL + 1C + Linux
т.е. я как то привык что у заказчиков брендовые СХД за много денег, и там Write Back всегда есть. Один раз была ситуация когда он отключился и долго не могли найти причину почему все операции записи стали выполнятся долго, и все стало подтормаживать.  

Т.е. 3000 мб/в сек это хорошо, но это же работает так что у тебя 8 каналов, каждый канал условно за 110 ns пишет данные во флеш.

Но вот если тебе нужно 16 потоков, то уже следующие 8 запишутся за 110+110 т.е. 260 ns.
При этом если все это под кэшем с батарейкой то все 16 операций получат fsync за примерно 60ns (50 латентность памяти кэша и еще 10 ns оврхед контроллера).


Я часто вижу пропускную способность в характеристиках и не встречал латентность.

Пример из жизни, серверная память, если смотреть пропускную способность в 8 канальном режиме, там какие то не реальные цифры, в 320 гб в секунду.
А смотришь на латентность а там 79 ns (для DDR3 1866).
источник

{o

{o o} in PostgreSQL + 1C + Linux
и тут интересно что если даже у тебя под контроллером с WB обычные диски, пока буфер не заполнился у тебя все fsync будут выполнятся за 60 ns. И для некоторых профилей нагрузки может получится что fsync на hdd под контролером с WB будет стабильно быстрее чем fsync на чистом EVO 960. (например пишем не так много данных по МБ но очень часто и быстро, при этом буфер не успевает заполниться).
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
Сравниваю 983dst vs pm983
источник
2021 April 14

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
и вот что пишут:
итоге: для сервера 1С/СУБД RAID-массив из NVMe SSD в большинстве случаев не является необходимым ни для ускорения, ни для повышения надёжности.
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
два pm983 заказал. хочу средствами mdadm в raid1
источник

AT

Alex Tkachuk in PostgreSQL + 1C + Linux
Для 1с - не надо дурной производительности, для постгри - надо
источник

AT

Alex Tkachuk in PostgreSQL + 1C + Linux
Вообще результат там конечно странный в произвольности, мы местами используем рэйд 5 и даже не на 10 дисках а меньше и буст по записи тоже есть
источник

AT

Alex Tkachuk in PostgreSQL + 1C + Linux
Мб рэйд контроллер не могёт
источник

И

Иван in PostgreSQL + 1C + Linux
Можно сослаться на это, когда тебя будут увольнять.
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
ого. Это еще почему?) Как рейд связан с трудоустройством\увольнением?)
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
на сервере 1с тоже генерит кучку временных файлов. Но, в целом, согласен
источник

А

Андрей in PostgreSQL + 1C + Linux
когда упадёт диск, который в соло:)
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
если
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
Ну сами подумайте, насколько критичен простой в два\три часа, если диски выбираются из бюджетного сегмента. массив строится из палок и других связующих.
источник

EN

Evgeny Nasedkin in PostgreSQL + 1C + Linux
1. тушим сервер.
2. выковыриваем диск.
3. вставляем диск
4. копируем бэкап.
5 стартуем сервисы.
источник