Комментарии 113
Лично по мне так огромнейшее время тратится на передачу контекстов форм с клиента на сервер и обратно
Самого давно интересует этот вопрос, спасибо за статью. Но я не вижу очень существенного параметра (проглядел?) - размер базы и количество документов. Судя по скоростям, база какая-то микроскопическая. Вы уверены, что ваши данные не целиком влезали в кэш дисков и вы не измерили именно его?
Размер базы - 6,5 Гб в файловом варианте, объем кэша LPDDR4 970EVO 512 мб, так что точно нет. Что касается по количеству документов, то 76440 за тестируемый интервал (6 лет)
объем кэша LPDDR4 970EVO 512 мб
нет, память на ssd используется для хранения таблицы транслятора (ftl), а не для кэширования чтения.
зато операционная система использует всю свободную память для кэширования.
BTW, кстати, не может оказаться, что снижение производительности в случае рамдиска было связано с уменьшением объёма доступной памяти?
76440 за тестируемый интервал (6 лет)
явно не хватает тестирования с серверным накопителем.
в синхронной записи (а СУБД на каждую транзакцию делает как минимум одну синхронную запись в wal) 970 evo показывает всего ≈500 iops
https://docs.google.com/spreadsheets/d/1E9-eXjzsKboiCCX-0u0r5fAjjufLKayaut_FOPxYZjc/edit?hl=en#gid=0
не понимаю тяги к использованию десктопных накопителей под серверные задачи.
А я понимаю, потому что бюджет. Для подавляющего числа средних компаний с базами размером до 20 Гб никакого смысла в серверных накопителях нет. Да, у них выше надежность и скорость, но если у вас месяц закрывается за 20 минут и на обычных, то скорость серверных вам не нужна, а в смысле надежности проще за стоимость серверного докупить два таких же бытовых HDD на 8 или уже даже 16 Тб, и бэкапить туда базу и журнал почаще, да и все.
Мы себе такого позволить не можем у нас масштабы побольше, поэтому живем на серверных U.2 Oculink но в этом случае стоимость всей платформы (мат. плата, кабели, диски) возрастает настолько, что меньшему бизнесу такие затраты просто не потянуть, он может на десктопных ПК собрать на ту же цену кластер из 3 машин с SATA рейдами в каждой, и их скорости дадут возможность бэкапится каждые 5 минут.
смысле надежности проще за стоимость серверного докупить два таких же бытовых HDD на 8 или уже даже 16 Тб, и бэкапить туда базу и журнал почаще, да и все
вы как-то не так смотрите цены. открываю московский магазин, pm9a3 на 960 гигабайт стоит 17 тысяч рублей, это даже не в два раза дороже, чем обсуждаемый в этой статье 970 evo той же ёмкости.
U.2 Oculink но в этом случае стоимость всей платформы (мат. плата, кабели, диски) возрастает настолько
во-первых, серверные nvme бывают и в m.2 формате (именно о таком я и писал выше).
во-вторых, адаптер для подключения u.2 в обычный слот pcie стоит на али меньше тысячи рублей, в розничных магазинах подроже, но всё равно не такие большие деньги.
он может на десктопных ПК собрать на ту же цену кластер из 3 машин с SATA рейдами в каждой
не смешно. я давно уже решил, что следующий домашний компьютер будет на eсс памяти, а вы предлагаете собирать «кластер» на десктопном железе и, очевидно, не-ecc памяти.
самое неприятное в не-ecc-памяти в том, что о проблемах с памятью вы не узнаете пока не запустите тест, то этого будет «ой, что-то программа вылетела», «ой, что-то база побилась»
"вы как-то не так смотрите цены" - нет вы :)
970 Evo можно установить и в ПК и в любой сервер, u.2 только в сервер с соответствующей платформой. Да, в серверной платформе может быть разъем m.2 и у меня она такая и есть, но он там один, массив сделать нельзя, бэкапится надо очень часто, а бэкап даже журнала плохо влияет на повседневную работу , если сервер уже и так загружен. Мат. плата с двумя и более m.2 или более чем двумя oculink стоит существенно дороже. Кабель oculink у нормального продавца это +3-5 т. р на каждый диск, а SATA-кабель или m.2 разъем условно-бесплатные, они в комплекте с мат. платой.
2. "на али меньше тысячи " - в сервер? Адаптер с Али? Спасибо, но я так делать не буду. В моем представлении любой приличный бытовой сата-диск надежнее адаптера с Али.
3. Т. е. вот память обязательно с ЕЦЦ, а адаптеры для хранилища - с Али. Это точно разумный баланс по надежности? У нас есть несколько ПК для тестирования баз и быстрых перепроведений с 64 Гб памяти без ECC и за годы их жизни, прогнав через эту память сотни терабайт данных мы не столкнулись ни с какими "битыми базами".
Вы как-то неправильно представляете себе работу памяти с ECC, она защищает только от флип-бита в случае внешнего воздействия, а от повреждения микросхем - никак нет. Может быть, можно настроить получение данных об ошибках памяти и температурах с сенсора, снимать их с ipmi, отдавать в мониторинг и тогда, действительно, узнать, но я нигде такого не видел и не слышал. А в обычно, ECC при повреждении ведет себя так же, как и non-ECC - ошибки и вылеты программ, проблемы с компиляцией. Линус Торвальдс не даст соврать:https://www.zdnet.com/article/even-linus-torvalds-sometimes-has-pc-problems/
Мат. плата с двумя и более m.2
… под Ryzen — явление давно уже рядовое
Линус Торвальдс не даст соврать
Это уже разбирали на хабре, и нет — память там была non-ECC
… под Ryzen — явление давно уже рядовое
Серверные материнки с парой М.2 или более — не особо рядовое. Хоть с Ryzen, хоть с Epic.
К слову, а драйвера ставите на буковки или на железо? Вопрос риторический.
Скажем, в том же dns-shop материнок на AM4 всего 63, с двумя разъемами M.2 — 37, и еще с десяток на 3 или 4 M.2.
У AsrockRack или 2 M.2 или M.2 + Oculink (больше касается мелких типоразмеров).
Не говоря уже, что для серверных применений, если уж заострять на них внимание, более актуален U.2 или разные SFF, а PCI-E, как справедливо заметили, прекрасно в эти M.2/U.2 конвертится.
970 Evo можно установить и в ПК и в любой сервер
честно говоря, не понял к чему вы это написали.
970 evo из статьи формата m.2, pm9a3, о котором я писал выше, тоже есть в том числе и в формате m.2
Т. е. вот память обязательно с ЕЦЦ, а адаптеры для хранилища — с Али. Это точно разумный баланс по надежности?
да. потому что адаптер в части pcie — тупой механический переходник.
в серверах у меня таких нет, но дома используется.
и если вам так претят китайские адаптеры, то есть вполне себе фирменные ретаймеры и свитчи, например в одном находящихся под моим присмотром серверов часть линий к бэкплейну подключена через свитч от intel. стоил не тысячу, но тоже каких-то не заоблачных денег.
(ретаймеры и свитчи нужны из-за того, что между разъёмом на материнской плате и накопителем/бэкплейном есть ещё полуметровый кабель, который вносит искажения в сигнал)
Вы как-то неправильно представляете себе работу памяти с ECC, она защищает только от флип-бита в случае внешнего воздействия, а от повреждения микросхем — никак нет
это вы неправильно представляете, ecc помимо защиты от случайных ошибок (которые, говорят, таки есть, но я у себя их не наблюдаю) позволяет обнаруживать сбои памяти и оперативно менять неисправные модули.
если вы верите, что сбоев памяти не бывает, значит у вас пока просто мало опыта.
Может быть, можно настроить получение данных об ошибках памяти и температурах с сенсора, снимать их с ipmi, отдавать в мониторинг и тогда, действительно, узнать, но я нигде такого не видел и не слышал
очень грустно за вас, это совсем не rocket science.
кстати, снимать ошибки ecc можно не только из ipmi, в linux, например, edac-util покажет ошибки (да и в dmesg будет сообщение); в случае аренды сервера у хостера бывает полезно.
1) Ставил размер диска в интервале от 12 Гб до 21 Гб - разницы не было
2) Как только появится в наличии серверный ssd - разумеется добавлю в статью. Постараюсь заказать в течение месяца
Так MS SQL всё равно сейчас не купить. Как можно сравнивать бесплатное с тем чего вовсе нет?
Есть доступный для бесплатной загрузки MS SQL Server 2019 for developers, ничем не отличается от полнофункциональной версии. И у многих уже купленные лицензии все еще есть, так что вопрос вполне актуальный. Тем более в свете необходимости планировать переход с MS SQL на Postgres - чтобы понимать, сколько именно производительности будет потеряно. Методика проверки в статье может быть неверной, но сама проблема актуальна. Тем более, что по моей практике, 1С сколько мощностей не дай, она все равно медленная. Если понимаешь, что станет еще медленнее, переход стоит отложить до выяснения подробностей.
"Сейчас" означает что не навсегда, а во вторых этот форум же читают не только в РФ, но и в других странах. Ну и плюс, разве не интересно сравнить условно бесплатный продукт (не забываем что покупку лицензии на сервер 1С никто не отменял) с платным?
Как вообще можно рассматривать файловый режим как рабочий. Это же какой-то франкенштейн из 90х годов, готовый упасть в любой момент
Например из-за стоимости лицензии на сервер 1С, а x64 версия сервера ещё дороже. А при использовании в связке с веб-сервером становится возможно работать на HDD с файловой
А что с файловым не так?
Вы предлагаете на компьютере каждого бухгалтера поднимать sql сервер?
Файловый это стабильный быстрый и удобный вариант.
А клиент-серверные решения применяют для большого количества пользователей.
Большая часть пользователей 1с работает как раз на файловом варианте.
Он в 100500 раз быстрее и уместнее, когда ты, скажем, бух на фрилансе, ведущий кучу баз всяких ИП со своего ноута. Скули разворачивать для таких целей нет необходимости. Достаточно решить вопрос с бэкапами и в принципе можно работать.
если база не большая у не большой конторы то смысл им покупать 1с сервер и городить это всё с БД на 1-2 пользователей? а таких случаев много
Все зависит от задач и объема базы. У моих клиентов файловые варианты живут 10 летние уже. Задачи потребности и возможности у всех разные. Скул версии предполагают покупку 1с сервера.
Другой вопрос в том, что в случае использования файловых версий, помимо скорости дисковой подсистемы, важна скорость и тайминг ОЗУ, уже лет 5 как или больше. Тест Гилёва не даст соврать. :)
Но статья не об этом и внимание этому аспекту не уделено.
до 20 гигов и пары пользователей более менее сойдёт. Не у всех есть деньги на лицензии и содержание специалиста SQL
А чем создавали RAMDisk? У таких программ часто разительно отличаются результаты в синтетических бенчмарках. Вплоть до опции принудительной эмуляции жёсткого диска
Не указано потребление памяти в каждом случае, объём занимаемых данных на диске во всех 3х случаях хранения (файлы/MS/PG). Не приведён конфиг для Postgres. Может у Postgres по умолчанию выставлен маленький кэш, а у MSSQL большой.
По мотивам https://infostart.ru/1c/articles/962876/ - OnlineAnalyze.enable включен и Postgres поддерживает этот патч ?
Спасибо за вопрос, я ждал его. В скором времени я хочу провести второй тест. Все настройки в данном тестировании у меня по дефолту. Мне нужны были "стандартные" результаты при установке по умолчанию. Теперь, когда у нас есть информация при дефолтных данных, я хочу сравнить какие можно получить результаты если постараться оптимизировать настройки MS SQL и POSTGRES SQL.
Можете в статье указать какие параметры были у postgres? Интересно можно ли в вашем случае подтянуть pg по скорости. Есть ещё платный postgres pro, интересно его с версией от 1с посмотреть.
Уже ответил выше:
Все настройки в данном тестировании у меня по дефолту. Мне нужны были "стандартные" результаты при установке по умолчанию. Теперь, когда у нас есть информация при дефолтных данных, я хочу сравнить какие можно получить результаты если постараться оптимизировать настройки MS SQL и POSTGRES SQL .
Что касается postgres pro - не обещаю но попробую добавить его если будет возможность
Установки по дефолту вещь своеобразная. Например сборка postgresql от 1с настроена на параметры по умолчанию которые тащатся в postgresql с незапамятных времен (а это примерно двух ядерный компьютер с 1ГБ ОЗУ и жестким диском, а например сборка от ПостгресПРО выполняет после установки скрипт который пытается хоть немного подстроить параметры СУБД под текущие параметры системы где устанавливается. MS SQL при работе часть параметров динамически подстраивает под оборудование. Так что сравнение производительности получается не очень корректное.
Правильно настроеный Postgres на ZFS вообще не уступает MS SQL. Главное бутылочное горло 1C это скорость одного потока процессора.
Возможно, я попробую поэкспериментировать с этой файловой системой после второго этапа тестирования. Но есть один нюанс - серверов под LINUX у меня нет в обеспечении. Как вариант можно заставить Windows понимать ZFS. Хотя это было бы интересное сравнение... В общем, пока могу сказать что подумаю на счет тестов на этой фс
Попробуй конечно, но у меня в 2016 году "правильно настроенный" закрывал месяц в течении недели. Стоковый MS SQL - 15 минут. (База около 80GB)
Возможно постгрес и вырос с тех пор, но насчет я не ZFS не уверен.
В 16 году с оптимизацией связки 1С и postgresql было всё печально. На данный момент сменилось слишком много версий 1С и postgresql. Тот опыт уже не актуален.
Ничего не изменилось, 100Гб база закрывает месяц 3 дня. На МС - 16 часов.
Подозрительно большая разница. Складывается ощущение, что на MS SQL все запросы живут с MAXDOP 0, а на PostgreSQL параллелизация запросов сильно ограничена настройками.
Да, МС тестировал в дефолте - себестоимость считается одним запросом на много часов, в МС распараллеливается на все ядра. В postgres запрос выполняется на одном ядре. Я пробовал распараллелить, но не смог. Там запрос вида INSERT INTO pg_temp.tt817 ...
Я на инфостате нашел статью про параллелизм и сравнение МС и посгрес. Там указано что в стандартной postgres работа с pg_temp не параллелится. PGpro вроде говорят, что внедрили у себя параллельную работу с временными таблицами, но я не проверял. У них вроде нет демо доступа, надо покупать.
Читали https://infostart.ru/1c/articles/962876/ про OnlineAnalyze.enable для включения индексов во временных таблицах ? В 2016 его не было.
Ну и по выводом это статьи (2019 год), на Linux в 1.3-1.5 раза быстрее.
В последних версиях платформы analyze для временных таблиц выполняется и без этого плагина. Так что он не нужен больше. Это с 8.3.18 или 8.3.19, точно не помню.
Ну и написано много где много чего. По факту на Linux в 2-3 раза медленнее.
INSERT INTO в ванильном PostgreSQL не параллелится. Но есть обходные пути.
Во-первых, можно сделать CREATE TEMP TABLE ... AS ... , что замечательно параллелится в ванильном PostgreSQL. Ну а результат потом перелить куда надо, если надо. Все равно он будет, преимущественно в оперативке сервера.
Во-вторых, можно писать в одну UNLOGGED таблицу из нескольких соединений, породив их, например, через dblink(). Этакий ручной параллелизим.
В-третьих, есть PostgresPro с патчем, который это позволяет, что Вы уже сами упомянули.
Ну и в-четвертых, патч для ванильного PostgreSQL для параллельного INSERT INTO мурыжится уже два года. Применять его самому не советую, но может дождемся еще его стабилизации и включения в mainstreem.
Регистрируешься на сайте, выбираешь версию и кликнешь да на соглашении о некоммерческом использовании продукта и получаешь дистрибутив pgpro под различные системы с детальным описанием установки
В 14 релизе postgres, по заявлениям производителя, добавлен алгоритм, аналогичный существующему в MySQL, который проталкивает наложение отборов ниже в структуре плана запроса .
В результате этого пресловутая проблема с производительностью по закрытию месяца должна уйти.
который проталкивает наложение отборов ниже в структуре плана запроса
Хм, а что именно вы имеете в виду?
Сейчас перепроверил
select * from
(select a.field1, b.field2 from a join b on …) с
where field1=xxx
условие field1=xxx было применено, как и ожидалось, до join
в MySQL
Это не опечатка?
https://habr.com/ru/company/postgrespro/blog/682976/
Вот такие изменения. Есть ключевые именно для 1С
А можно хоть наметки как правильно приготовить postgres на ZFS? А то я при экспериментах не получил выигрыша ZFS от других ФС для postgres.
Вкратце — нужно правильно распределить ОЗУ между ZFS ARC, postgres и остальной системой, включить в zfs как минимум для фс с postgres сжатие lz4 (zstd не дает выигрыша в производительности), а у postgres настроить effective_io_concurrency и отключить synchronous_commit и full_page_writes, так как целостностью данных управляет zfs. Ну и для полноты картины убедиться, что процессор работает в режиме максимальной производительности, а не энергосбережения.
Есть ещё ряд мелких настроек, дающих небольшой прирост производительности, но ни включение huge pages, ни отключение защиты от аппаратных уязвимостей процессоров mitigations = off не показали у меня увеличение производительности выше погрешности измерения.
Измерял тестом Гилёва, попугаи на не уступают конфигурациям с MS SQL.
Реальная производительность зависит от многих факторов, в т. ч. от версии платформы и конфигурации. С одной стороны, обновление платформы ухудшает показатели тестов на том же сервере. С другой — использование современных конфигураций может увеличить скорость работы в разы.
А то я при экспериментах не получил выигрыша ZFS от других ФС для postgres
CoW fs и базы данных не очень совместимы, обычно цель тюнинга zfs — чтобы получилось не сильно медленнее какой-нибудь ext4
Если речь идёт про уже имеющийся в наличии SATA SSD, то да, смысла особого нет при использовании СУБД MS SQL или POSTGRES, а если речь идёт про приобретение новых дисков, то разумеется, есть существенный смысл приобрести NVME
Нет, не так. Я не могу подготовить целую статью, времени нет и сил нет, но я проводил такие тесты:
База на MSSQL + Raid10 x4 SATA + журнал на другом Raid10 x4 SATA
и
База MSSQL + Raid1 x2 NVME U.2 Oculink + журнал на одиночном NVME 2 Tb PCI-e.
NVME в такой конфигурации существенно быстрее. База 70 Гб, Конфигурация Бухгалтерия вер. 3, платформа 1.8.3.18 Количество документов не помню, в самом ненагруженном месяце примерно 27000, в квартал около 160000
Полное "Тестирование и исправление" базы со всеми галками на SATA - 22 часа, на NVME - 16. Закрытие месяца Sata 19 часов, NVME 9,9
По соотношению цена\скорость в тот момент выигрывал SATA потому что был гораздо дешевле, но для бизнеса была важнее скорость, потому что бухгалтерии работать надо, а не ждать, пока месяц закроется. Особенно когда база такая не одна.
Скажите, а при цене MSSQL вы все еще смотрите на цену дисков? Они же теряются где-то на фоне.
Мы смотрим
Нет, не теряются, посмотрите цены на 2 Tb U.2 - около 50.000 за штуку, а нужен Raid минимум из 2 шт, + кабели + мат. плата с разъемами oculink стоит на 40 Т. р. больше похожей без них
MSSQL мы купили давно и заплатили за него один раз, а диски желательно менять профилактически раз в три года, или уж если совсем затягивать, то раз в 5.
Множество других организаций не используют MSSQL или переходят с него на Postgres
UPD: А если вспомнить, сколько такие диски стоили в момент взлета криптовалюты "Чиа" и наводнений, разрушивших фабрики на Тайване и т. п., да еще умножить это не на 2 а на 4, потому что кластер...
ИМХО сравнивать накопители по единственному параметру — интерфейс — это плохая идея.
Тут я полностью с вами согласен, но мы все дружно сидим и ждем, пока найдется добрый человек, или организация с бесконечным бюджетом денег и времени, которые кааак соберуться, каак выкатят нам массовый тест всех видов железа для 1С и best practice как это все готовить. Пока не дождались и читаем скупые рекомендации от 1С и инфостарт. Спасибо автору, потратил силы и время и сделал, что мог.
Что такое NVMe x3?
Если речь о PCI-E Gen 3, то надо так и писать. X используется для обозначения количества линий PCI-E, а никак не версии. А 3 линии у NVME в PCI - нонсенс
Для корректного сравнения файловой и серверных версий на RAM диск нужно переносить и служебные файлы SQL серверов. Например, для MS SQL нужно перенести базу Tempdb. Эта база активно используется при перепроведении документов. Не увидел информации об этом в статье.
Хотелось бы отметить, что Windows для PostgreSQL инородная среда, под которой оценивать его производительность уж точно не стоит. По двум причинам:
Во-первых, PostgreSQL каждый объект БД (раздел таблицы, индекс и т.п.) хранит в отдельном файле. А производительность даже древней ext3 при больших количествах файлов в одной директории, заметно выше, чем NTFS. Что уж говорить о современных файловых системах? В MS SQL эта проблема решается просто отказом от работы с файловой системой в процессе работы сервера и размещением всех объектов БД в одном или нескольких постоянно открытых файлах.
Во-вторых, PostgreSQL активно пользуется fork(), реализация которого под Windows далека от оптимальной. В первую очередь из-за отсутствия Copy-on-Write. Иными словами, если под Linux fork() выполняется почти мгновенно, откладывая копирование страниц памяти на потом, и только при их модификации, то под Windows такой возможности нет и при fork() выполняется принудительное копирование всей памяти процесса.
А производительность даже древней ext3 при больших количествах файлов в одной директории, заметно выше, чем NTFS
слушайте, это тут вообще не к месту. ни по количеству файлов в каталоге (десятки-сотни-тысячи не являются проблемой ни для какой фс), ни по характеру использования (тормозит открытие файла; СУБД же, очевидно, держит файлы БД постоянно открытыми, а не открывает/закрывает их при каждом обращении)
У меня есть каталог на windows 2008r2 - сервере, лежащий на Raid1 из жестких дисков, в NTFS, где лежат несколько милионов документов в нескольких сотнях тысяч папок. Сколько именно я не могу сказать, потому что не могу ни зайти в него проводником, ни посчитать их скриптом powershell, сервер при этом зависает намертво. Диски в порядке и по смарту и по тестам поверхности и ФС chkdsk.
И есть копия этих же данных на Linux в Ext4, на одиночном диске. Там нет графического интерфейса, чтобы проверить, зайду ли я туда Наутилусом, но скрипты и du с ними работают вполне нормально. Считать их там я не пробовал, но разница даже по перемещению скрипта и подсчету занятого места явная
Во-первых, раз речь об 1С, количество файлов может оказаться под миллион, так как каждый раздел и индекс - отдельный файл. По крайней мере на первой попавшейся мне сейчас под руку продуктивной БД PostgreSQL 500 таблиц хранятся в 7 тысячах файлах.
Во-вторых, это MS SQL держит все файлы открытыми, так как их у него на пальцах можно пересчитать. PostgreSQL так не делает и открывает/закрывает файлы по мере надобности в них. И в том то и проблема, что на современных FS в Linux операции открытия/закрытия файлов при работе PostgreSQL занимают меньше миллисекунды (не забываем об указании noatime,nodiratime при монтировании), тогда как на NTFS - несколько миллисекунд. Оба времени - с учетом кеширования.
Во-первых, раз речь об 1С, количество файлов может оказаться под миллион,
не может
так как каждый раздел и индекс — отдельный файл. По крайней мере на первой попавшейся мне сейчас под руку продуктивной БД PostgreSQL 500 таблиц хранятся в 7 тысячах файлах.
чтобы число файлов выросло до миллиона, надо или создать миллион таблиц/индексов (чего в стандартных конфигурациях явно не бывает), или в существующие записать петабайт (ЕМНИП постгрес создаёт по файлу на гигабайт)
PostgreSQL так не делает и открывает/закрывает файлы по мере надобности в них
так увеличьте max_files_per_process. 1с рекомендует 8к как начальное значение, и увеличивать с ростом базы.
https://its.1c.ru/db/metod8dev/content/5866/hdoc
Для того, чтобы число файлов PostgreSQL выросло до миллиона, достаточно несколько десятков тысяч таблиц, что я легко наблюдал на производственных предприятих. Любая таблица без индексов - уже минимум три файла (данные, карта свободного места и карта видимости). Каждый индекс - два файла (индекс и карта свободного места). То есть, одна таблица с восемью индексами - два десятка файлов. И это не считая вороха временных таблиц на каждого пользователя.
"Под миллион", как я писал выше - это фактическая картина для 1С на предприятии по производству ювелирных часов.
И при чем тут количество файлов для серверного субпроцесса? Эти субпроцессы форкаются в PostgreSQL по десятку-другому на один запрос.
Для того, чтобы число файлов PostgreSQL выросло до миллиона, достаточно несколько десятков тысяч таблиц, что я легко наблюдал на производственных предприятих. Любая таблица без индексов — уже минимум три файла (данные, карта свободного места и карта видимости). Каждый индекс — два файла (индекс и карта свободного места). То есть, одна таблица с восемью индексами — два десятка файлов. И это не считая вороха временных таблиц на каждого пользователя.
"Под миллион", как я писал выше — это фактическая картина для 1С на предприятии по производству ювелирных часов.
ваши оценки: под миллион файлов, по файлов на таблицу — итого выходит многие (не один-два) десятки тысяч таблиц.
я такого не видел. и не хотел бы увидеть.
И при чем тут количество файлов для серверного субпроцесса? Эти субпроцессы форкаются в PostgreSQL по десятку-другому на один запрос
вы про распаралеливание запросов? нет, параметр был ещё до этого:
https://www.postgresql.org/docs/8.1/runtime-config-resource.html
если я правильно понимаю, он означает как много открытых файлов может быть в серверном процессе (читай клиентском подключении), при превышении этого числа процессу придётся закрывать какие-то из открытых прежде файлов (а при повторном обращении к ним открывать их снова)
хотя я был неправ, похоже.
задирание этого параметра может кардинально снизить потребность в жонглировании закрытием/открытием файлов в уже существующем подключении, но никак не повлияет на открытие файлов в начале подключения.
впрочем, у меня есть сомнения, что задержки на это самое открытие файлов в начале подключения существенно влияют на производительность 1с.
Дело в том, что на больших БД, во-первых, активно используют частичные индексы. И таких индексов на таблице может быть несколько десятков. Во-вторых, для удобства архивирования старых лет и повышения производительности, все транзакционые таблицы (документы, регистры и т.п.) партиционируются по годам. А каждая партиция, с точки зрения PostgreSQL - отдельная таблица со своими индексами. Так что, если горизонт хранения лет 10 (что совершенно нормально, если убытки в первые годы работы покрываются потом прибылью последующих лет), такое количество файлов получить несложно.
Что если это проблема windows, а точнее конкретной программы для создания виртуального накопителя? Для объективности надо сравнить с tmpfs в linux.
Долго боролись мы с 1С и её тормозами... в итоге пришли к следующему решению: сиквельную базу оставили на старом сервере с рейдами, а клиентскую часть я затолкал в новый сервак в виртуалку. Правда изначально этот сервер предназначался под файловое хранилище. Первое время было нормально, но после нескольких обновлений 1С стало ужасно тормозить. Самое интересное, что по производительности, не потребляется ничего, кроме оперативы, но чем больше пользователей входит, тем сильнее тормоза.
Оперативы было выделено 12ГБ, 2 проца Bronze 3106 (1,7ГГц)... работает обычно 12-15 клиентов. Как я говорил, занята была только оператива (до 97%) при полной загрузке... очередей по диску почти нет: изредка кратковременно очередь доходила до 5. По итогу, люди ждали загрузки 1С по несколько минут.
Чисто ради эксперимента перетащил виртуалку с клиентами на старый временный сервак (i5 10400, 16ГБ под виртуалку)... и скорость существенно выросла, но не идеально... и по прежнему загружена была только оператива.
На новом сервере рейд-массив 10 на хардах... на временном серваке обычный хард (по сути это обычный комп)... на обоих система работает на SSD.
Кто может объяснить что нужно этой 1С? Контора, которая обслуживает 1С, не может нам ничего сказать... регулярно что-то обновляют в ПО, но ничего не меняется в скорости в лучшую сторону. Как увидеть реальную потребность 1С в ресурсах? Я предложил проапгрейдить процы на сервере до 4115R + добавить 64ГБ оперативы... но будет ли от этого существенный прирост в скорости - не понятно. Самое обидное, что организация готова платить, но за что?
Когда у нас встала задача оптимизации, мы начали с изменения конфигурации. Перевели все блокировки на управляемые, тем самым ускорив параллельную работу пользователей. Сейчас не знаю, но несколько лет назад перевод MSSQL в режим версионника тоже давал ускорение.
К сожалению, по нашему опыту улучшить производительность 1С "завалив" ее новеньким быстрым оборудованием получается, но совсем не так, как хотелось бы. Прирост мощностей в "попугаях" + 250% а быстродействия 1С - 25-30%.
Однако и это уже хорошо.
Обновления ПО на старом железе ухудшают ситуацию, потому что новое ПО приспосабливают делать работу быстрее, потребляя больше ресурсов и адаптируя под новые аппаратно реализованные алгоритмы.
1С очень любит частоту процессора а не количество ядер, потому что многие операции невозможно (или разработчики 1С не умеют) разделять в многопоток. 1.7 Ггц и 12 Гб это очень мало для нее. Рассчитывайте минимум 4 Гб на платформу, лучше 8, +2 Гб на каждого пользователя. А в моменты перепроведений месяцев\кварталов оно способно сожрать 256 Гб ОЗУ в зависимости от вашей базы и объема документов.
В нашем случае 4115R принес ускорение, но не сам по себе, а в сочетании с NVMe дисками и увеличением ОЗУ.
UPD: Харды для 1С это смерть. Если хотите попробовать ускорится бюджетно, мы делали еще такой вариант: Мощный десктопный комп на Ryzen 7 3ХХХ (сейчас лучше 5ХХХ) с максимальной частотой и минимум 8 Ядрами, мат. плату с минимум 64Гб (желательно 128) ОЗУ и поддержкой 2 NVMe PCI-e 3.0 или 4.0. Систему на рейд из SATA SSD, Платформу и базы на NVMe, журналы и кэши на другой NVME. Все это уделает ваши чахлые "Bronze" в разы.
Всё понял, спасибо!
Оператива уже была закуплена некоторое время назад (64ГБ)... но "не взлетело": как оказалось, она совместима только со вторым поколением процов, а стоит первое (об этом нет нигде информации, выяснилось только по факту... и то, производитель ответил вот так: пробуйте обновить бивас... если не поможет - нужно 2е поколение процов).
Поэтому сейчас смотрю в сторону 4215R (не 4115 - опечатался) + NVMe на сервер с базой.
Сейчас база лежит на хардовом сервере с оперативой 64ГБ (через пару недель она сжирала 30 гигов и начинала ещё больше тормозить: помогала перезагрузка... недавно немного подрезали аппетит СУБД), но процы там тоже унылые. Соединены серваки по 1Гб.
ЗЫ: и всёравно я недоумеваю: почему не видно нагрузки на подсистемы... любой другой софт займёт все свободные ресурсы, пока ему не будет достаточно... а тут всё по минимуму и тормозит...
Ну у нас 4215R - все не очень быстро. Там в разгоне все ядра 3.6Ггц, и в однопотоке 2300 попугаев. Я для тестов поставил на i5 10400 - там 4Ггц и 2600 попугаем - стало значительно лучше. Так что для 1с хорошо идут мощные десктопы типа i9 12900. Или Intel® Xeon® E-2388G - там колоссальные 3500 в однопотоке, это перебивает практически любые остальные опции в сервере.
"ЗЫ: и всёравно я недоумеваю: почему не видно нагрузки на подсистемы... " Сам испытываю те же чувства, но магией мониторить правильные показатели для работы 1С владеют не только лишь все. Я не владею. Я смотрел в sysmon\resmon и глубину очередей по дискам и ввод-вывод по процессам, пытался заглядывать в распределение памяти и в своп. В результате пришли к выводу, что повседневная производительность после апгрейда - хорошая, а по перепроведениям из абсолютно неприемлемой стала минимально достаточной, а для дальнейших улучшений нужен либо бюджет на еще больше быстрого железа, либо на найм аутсорса, который как раз все правильно помониторит, оптимизирует и почистит базу и т.д. Ни на то ни на другое денег пока нет.
честно говоря, я из вашего описания вообще не понял кто на ком стоял.
sql-версия? где лежит база? где запущен сервер приложений? клиенты толстые/тонкие? где запущены?
Раз с железом чехарда, надо смотреть настройки сервера 1с. Или у Вас файловая версия?
Для сервера 1С уменьшаем количество соединений на процесс до минимума от версии. Инструкцию под Стандартный сервер, корп сервер искать на инфостарте.
Для сервера 1С %Appdata% и %temp% на одно дисковое устройство, базу данных на другое. Тюнинг ос. Регулярная очистка кэша 1с.
При открытии тормозит из-за журнала 1с: читать как увеличить производительность и правильно работать с журналом 1С на инфостарте, хабр.
А еще долго может искать лицензии hasp в сети на клиентах. Как раз минуты две таймаут. Настроить поиск по ip адресам машин с хаспом или выдавать лицензии сервером 1С.
Спасибо, проверю...
Сервер лицензий 1С'ники вынесли на отдельный комп на *nix'е... Адрес в резерве. Кстати совсем недавно были проблемы с лицензиями: постоянно жаловался на нехватку, хотя сессий хватает. После долгих жалоб это поправили, но начались сильные тормоза.
Тормоза не только в долгом запуске, но и в элементарной работе: выпадающие менюшки падают через несколько секунд после клика и т.п.
Выпадающие менюшки: клиент и журнал регистрации...
Опять же надо понимать, что за конфигурация, режим запуска толстый, тонкий клиент.
Можно организовать веб-доступ, если конфигурация позволяет и перевести клиентов на доступ через веб. Соединений к серверу за счет этого меньше будет, скорость повысится
А клиенты где? На том же сервере? Или тонкие?
Если на том же - памяти очень мало. Да и в принципе мало, 16Гб - это только для 1с, для БД отдельно нужно.
1с очень любит частоту ядер. У Bronze 3106 (1,7ГГц) очень низкая, все будет мертвое. У i5 10400 в принципе норм, для 15 человек сойдет.
Ну и CCД под базы, никаких хардов.
А настройки postgres менялись перед тестированием? Или использовались из коробки? Какая версия Postgres?
Заранее прошу прощения, если пропустил выше, но:
Не повлияло ли на тестирование размещение %temp% и прочих сервисных директорий на самом медленном диске в тестировании диска RAM? Мне кажется, по своему опыту, что ОЗУ должно выдать производительность на уровне SSD на PCI шине. Возможно, драйвер виртуального диска в ОЗУ требует настройки?
Мне кажется, по своему опыту, что ОЗУ должно выдать производительность на уровне SSD на PCI шине.
нет, конечно же, намного выше. другое дело, что получить измеримую разницу можно зачастую только в синтетических тестах.
пример: задача считается час, из этого часа она ожидает накопителя 5 секунд.
как ни оптимизируй производительность дисковой подсистемы, больше 5 секунд выиграть не получится (и эти 5 секунд «утонут» в разбросе длительности исполнения при разных запусках).
Проблема в том что найти RAM диск который поддерживает хороший конкурентный доступ проблема. Вот по тому же Softperfect ктото уже на саппорт писал Concurrent read and write performance - RAM Disk Help (softperfect.com) но судя по всему четкого ответа не получил
По опыту знаю что даже в серьезных системах часто диспетчера, который разруливает конкурентный доступ, вешают на одно ядро и когда оно загружается на 100% все становится в очередь. Если кто найдет хороший RAM диск с конкурентным доступом пишите
Тестирование скорости работы 1C в режиме файловой версии, MS SQL и POSTGRES на HDD, SSD и RAMDisk