Вход | Регистрация

  1  2  3  4   
Информационные технологии :: Администрирование

Вопрос по Postgresql

Вопрос по Postgresql
Я
   ВикторП
 
17.01.18 - 12:29
Установил Postgresql - с сайта Postgres pro под Windows- самая последняя 9.6 для 1с.

Выполнил рекомендации из ИТС и gilev.ru/postgres. Что на ИТС, что у Гилева встречаются настройки, которых нет в конфигурационном файле, например checkpont_segmens . Из рекомендаций Гилева мне не подошла настройка effective_io_concurrency - c подобной настройкой PG не стартует.


Сравниваю производительность баз данных под MS SQL и Postgresql , поэтому базы подняты с одного dt и выполняю одинаковые длительные обработки на одном и том же компьютере, обе СУБД на одном сервере.

Вот что я заметил. Время выполнения на обоих СУБД почти одинаковое, MS SQL почти всегда быстрее , но не критично , примерно 10%, диски под MS SQL производительней, все файлы PG на одном диске, поэтому такая разница устраивает и понятна.



НО... при втором, третьем выполнении этой же обработки, время на MS SQL уменьшается очень сильно, а на PG - уменьшения - нет .Вообще.

Например , один тест - под MS SQL 10 мин- первый запуск, 7 минут - второй запуск. Под PG- все время 12 минут.(Времена округленные).
второй тест под MS SQL первый прогон- 37, второй- 31 минута. Под Postgresql . Самый первый прогон - 50 минут, после vacuum full verbose analyze и изменения конфигурационнойго файла- 35 минут и на этом все, следующие прогоны вокруг этой цифры, уменьшения нет.


Можно ли добиться использования кеша 1с настройками Postgresgl? Или это не кэш?
 
 
   Hmster
 
1 - 17.01.18 - 12:36
Возможно вы задали мало памяти и он тупо не кэширует БД. Тут надо смотреть размеры памяти в конфиге и на сервере, размер самой БД, что за тест.
ПГ так же очень критична к запросам, плохо переваривает кривонаписанные.
   piter3
 
2 - 17.01.18 - 12:41
ОС винда?
   ВикторП
 
3 - 17.01.18 - 12:41
мало памяти- это какая настройка.
сама база 17 гб.

Один тест- проведение по партиям - стандартная в УТ10
второй тест - самодельная обработка с очень неоптимальными запросами.
   mistеr
 
4 - 17.01.18 - 12:42
(0) Одно из отличий Postgres от MSSQL в том, что ему нужен толковый админ сразу, а не когда база за терабайт перевалит.
   mistеr
 
5 - 17.01.18 - 12:43
(4) > с очень неоптимальными запросами.

Посмеялся, спасибо. :D
   ВикторП
 
6 - 17.01.18 - 12:43
Комп клиентский - Win 7, сервер- Win server 2008 r2
   ВикторП
 
7 - 17.01.18 - 12:44
(5) посмеялся , молодец.
   piter3
 
8 - 17.01.18 - 12:51
(6) Может стоило тестить слона на профильной ОС.
   ВикторП
 
9 - 17.01.18 - 12:56
(6) может. Скоро буду.
Сейчас я тестирую на тестовом сервере на тестовых базах.

Ожидал увидеть большую разницу в пользу MS SQL. И удивился небольшой разнице.

Но про кэш узнать хочется.
   Lama12
 
10 - 17.01.18 - 12:59
(0) В винде за использование памяти в Postgre, отвечает операционка. Рекомендую поставить данную СУБД на Linux и провести настройки.
 
 Рекламное место пустует
   mistеr
 
11 - 17.01.18 - 13:08
(9) Озвучь размер БД и размер буферного кэша.

Скуль по дефолту не ограничен по памяти, может легко затянуть хоть всю базу. А для Постгри в конфиге жесткий размер кэша задается.
   ВикторП
 
12 - 17.01.18 - 13:15
(11)

Размер базы я писал выше- 17 гб.

shared_buffers = 6GB
effective_cache_size = 18GB

или что-то другое?
   mishaPH
 
Модератор
13 - 17.01.18 - 13:17
(4) +100 аж консалтинговую компанию привлекли для настройки и поддержания посгреса. В итоге помоему лицензия от мс детский лепет по стоимости чем поддержка крупных систем на посгресе.
   ВикторП
 
14 - 17.01.18 - 13:22
(13) у нас не крупная система.
Кого привлекли?
   ИТ директор
 
15 - 17.01.18 - 13:29
(13) в итоге стоимость поддержки постгреса стала сопоставимой по стоимости лиц. отчислений Оракла? :)
   ИТ директор
 
16 - 17.01.18 - 13:32
Постгрес ублюдочный по своей архитектуре и без допилов ядра на высоконагруженных системах не работает.

https://www.youtube.com/watch?v=ID_W5nMi8cE

А в прошлом году слонятники отмечали 20-летие.
   ВикторП
 
17 - 17.01.18 - 13:40
Не все так думают.

https://www.youtube.com/watch?v=pe_dwL38_o8
   ansh15
 
18 - 17.01.18 - 15:34
(0) effective_io_concurrency в Windows не работает.
PostgreSQL служба не запускается
(12) О shared_buffers в документации к PostgreSQL пишут, что
"большие значения shared_buffers не так эффективны в Windows. Возможно, вы получите лучшие результаты, если оставите это значение относительно небольшим и будете больше полагаться на кеш операционной системы. Оптимальные значения shared_buffers для Windows обычно лежат в интервале от 64 до 512 мегабайт."
https://postgrespro.ru/docs/postgrespro/9.6/runtime-config-resource
   ВикторП
 
19 - 17.01.18 - 15:46
Про shared_buffers  отсюда

https://its.1c.ru/db/metod8dev#content:5866:hdoc
   ВикторП
 
20 - 17.01.18 - 16:09
(18)

На постргреспро с вашей же ссылки написано совсем не то, что вы пишете

shared_buffers (integer)
Задаёт объём памяти, который будет использовать сервер баз данных для буферов в разделяемой памяти. По умолчанию это обычно 128 мегабайт (128MB), но может быть и меньше, если конфигурация вашего ядра накладывает дополнительные ограничения (это определяется в процессе initdb). Это значение не должно быть меньше 128 килобайт. (Этот минимум зависит от величины BLCKSZ.) Однако для хорошей производительности обычно требуются гораздо большие значения. Задать этот параметр можно только при запуске сервера.

Если вы используете выделенный сервер с объёмом ОЗУ 1 ГБ и более, разумным начальным значением shared_buffers будет 25% от объёма памяти. Существуют варианты нагрузки, при которых эффективны будут и ещё большие значения shared_buffers, но так как Postgres Pro использует и кеш операционной системы, выделять для shared_buffers более 40% ОЗУ вряд ли будет полезно. При увеличении shared_buffers обычно требуется соответственно увеличить max_wal_size, чтобы растянуть процесс записи большого объёма новых или изменённых данных на более продолжительное время
   ansh15
 
21 - 17.01.18 - 16:34
(20) То, что процитировано в (18), идет следующим абзацем.
   ВикторП
 
22 - 17.01.18 - 16:49
У меня не случай сервера с 1 гб оперативки
   mistеr
 
23 - 17.01.18 - 19:58
(12) >effective_cache_size = 18GB

Откуда значение? Советую сбросить на дефолт.

Это размер кэша. Это подсказка оптимизатору, влияет на планы запросов. Если будут неоптимальные планы, то сам понимаешь.
   mistеr
 
24 - 17.01.18 - 19:58
(23) *Это НЕ размер кэша№
   mikecool
 
25 - 17.01.18 - 21:30
(0) постгри надо ставить на линухе
   Веселый собака
 
26 - 17.01.18 - 21:59
(25) Да, а то двойная глупость получается, ставит на платную ОС, под которую пг условно заточен, а потом жалуется )
   novichok79
 
27 - 18.01.18 - 00:20
(0) молодец мужик, даже тесты запускаешь. подписался на тему.
   ВикторП
 
28 - 18.01.18 - 09:25
(23)
effective_cache_size = RAM-shared_buffers

Это размер кэша файловой системы

Мной взято с gilev.ru
   Arh01
 
29 - 18.01.18 - 10:10
(14) Если вы готовы платить деньги за консультацию и настройку может обратится к профи https://postgrespro.ru/services ?
   Фрэнки
 
30 - 18.01.18 - 10:16
И вот интересно, если "для тестов" выдергивать с сайтов поставщиков или разработчиков самые последние выпуски ПО, а при этом же использовать инструкции и лайф-хаки, которые были написаны намного раньше этих выпусков?
   arsik
 
31 - 18.01.18 - 10:21
(0) Для начала вот неплохое видео
https://pgconf.ru/2017/93686
   ВикторП
 
32 - 18.01.18 - 10:23
(30) дайте ссылки на актуальные лайф-хаки
   ВикторП
 
33 - 18.01.18 - 10:24
(31) спасибо за ссылку
 
 
   arsik
 
34 - 18.01.18 - 10:26
(32) Вот полный мануал. И все по русски
https://postgrespro.ru/docs/postgrespro/9.6/index.html

Для начала от туда нужно вот это:
https://postgrespro.ru/docs/postgrespro/9.6/runtime-config.html
   ВикторП
 
35 - 18.01.18 - 10:28
Про постгрес про я в курсе. Я не нашел там по теме топика- кэшу 1с. Может, плохо искал.
   ИТ директор
 
36 - 18.01.18 - 10:28
Я просто оставлю это здесь: интервью с экспертом postgres pro https://www.youtube.com/watch?v=JGLEvYsmdiM

Ребята одумайтесь зачем вам этот гемор.
   Провинциальный 1сник
 
37 - 18.01.18 - 10:30
Лучше бы 1с реализовала поддержку firebird, а не postgres..
   Fragster
 
38 - 18.01.18 - 10:33
можно еще многопоточную нагрузку потетсить с помощью http://catalog.mista.ru/public/173394/
   arsik
 
39 - 18.01.18 - 10:33
   ERWINS
 
40 - 18.01.18 - 10:39
(37) чем лучше?
   arsik
 
41 - 18.01.18 - 10:42
(36) Хрень какая то.
У нас 150 магазинов техники крутятся на постгре + linux. И это реально выгодно. Представьте сколько  нужно было бы потратить на MS решение.
   ИТ директор
 
42 - 18.01.18 - 10:46
(41) Ну естественно у вас для этого есть выделенный линукс админ+postgres DBA?
   trdm
 
43 - 18.01.18 - 10:46
(41) > Хрень какая то.
возможно такая хрень, что консалтеры настройщики слона просто груши пинали, а не работали, а потом за ИБД запросили круглую сумму. Свой хороший спец на постоянке надежнее.
   trdm
 
44 - 18.01.18 - 10:47
ну и ИТ директор скорее всего гешефт с продаж имеет. А такому персонажу опенсорц поперек гланд.
   Фрэнки
 
45 - 18.01.18 - 10:49
(41) не обращай внимания. Он из этих, как их там... майкрософтовских евангелистов.
Я когда-то давно тоже евангелистом от майкрософт был, пока меня не достало отсутствие денег за программирование на С++ - ну это давно было и тогда только за счет 1С и смог прокормиться, а все остальное пришлось в сторону отбросить
   ВикторП
 
46 - 18.01.18 - 10:50
(39) спасибо за ссылку. В моем конфигурационном  файле нет п.5 с расширяемыми библиотеками, видимо. Посмотрю.


Посмотрел. Все это есть. Ступил.
Я же устанавливал Постгри с их сайта, поэтому их настройки в конфигурационном файле уже есть изначально.
   Фрэнки
 
47 - 18.01.18 - 10:51
сам трабл продуктов от майкрософт даже не в том, сколько за это нужно заплатить, а в том, что ни фига не известно после того, как заплатил, а все ли дырки баблом заткнуты или еще косяки в лицензировании так и остаются неприкрытыми
   ИТ директор
 
48 - 18.01.18 - 10:58
Я не из мелкософтовских евангелистов, мне работать надо.

Я могу настроить продакшен базу на скуле со всеми необходимыми регламентами и мониторингами за пару часов, и потом только почту смотреть каждое утро что всё ок.

Я могу в течение часа найти и распарсить проблемный тяжелый запрос в SQL Sentry Plan Explorer и исправить его в 1С.

Чтобы сделать что-то наподобие в ваших линуксах - куинуксах и постгресах-куесах нужно заюзать кучу костылей и убить немеряно времени.
   ВикторП
 
49 - 18.01.18 - 11:01
(38) Я планирую нагрузочный тест из корпоративного инструментального пакета.

https://its.1c.ru/db/kip#content:40:hdoc
 
 Рекламное место пустует
   ВикторП
 
50 - 18.01.18 - 11:04
(48) найти "что-то" можно без SQL - по технологическому журналу
   novichok79
 
51 - 18.01.18 - 11:05
(0) у меня крутятся базы на PostgreSQL 9.6.6-1.1С. УТ 11.4, ЗУП 3.1, БП 3.0 и еще парочка тестовых. я настроил конфигурационные файлы postgresql по рекомендациям 1С с ИТС (очень старые доки не брал), посчитал некоторые параметры на сайте pgtune. основная рабочая база - УТ 11, в ней набивают реализации одновременно от 30 до 50 пользаков. размер папки базы в каталоге постгри около 30 Гб (прямо сейчас). пользаки на скорость не жалуются, не подвисает, работает стабильно (если можно так выразиться по отношению к УТ 11). нагрузочных тестов не проводил, ибо некогда пока. пару раз пришлось избыточные ведение логов включить в технологическом журнале, чтобы отловить долгий запрос.
   ИТ директор
 
52 - 18.01.18 - 11:05
А некоторые вещи сделать невозможно в принципе В постгресе-куесе нет диф. бэкапов - сюрприз-сюрприз. И кластерных индексов. А index only scan или включаемые столбцы преподносятся как чудеса инженерной мысли. И о чудо! ребята начали думать про адаптивный план запроса, который уже есть в продуктивном сиквеле. Проблему с временными таблицами они похоже так и не решили до сих пор, нужно дропать схему. Короче хотите трахаццо вместо зарабатывания денег - трахайтесь. Получайте за это зарплату линуксового админа, которая в 2 раза меньше 1С-ника, и будьте счастливы.
   Фрэнки
 
53 - 18.01.18 - 11:09
(52) ну зачем про зарплаты фантазировать-то?!

то у тебя админы линукса получают много, то они у тебя получают в два раза меньше, чем 1с-ник? Если получают меньше, то к чему тогда заявлять о дороговизне саппорта для постгри, которая съест всю экономию отказа от лицензий?

И еще. Т.е. проблема же все-таки не в том, что куплен МС-СКЛ или не куплен, а в том, что есть Специалист (с большой буквы!) на этот самый сиквел или его нет от слов "нет совсем"
   Фрэнки
 
54 - 18.01.18 - 11:12
(52) например, я "в живую" перед глазами не вижу спецов, которые регулярно-часто вынуждены делать вот это:
// в течение часа найти и распарсить проблемный тяжелый запрос в SQL Sentry Plan Explorer и исправить его в 1С //
   ИТ директор
 
55 - 18.01.18 - 11:13
(53) чувак где я говорю что админы линукса получают много? пруф будет? Консалтеры всякие типа Максима Богука или Ильи Космодемьянского наверно неплохо зарабатывают, но у них свои компании, а посмотри вакухи того же посгтрес про там шлак а не зарплаты.
   ВикторП
 
56 - 18.01.18 - 11:14
(51) Можете в какой- нибудь вашей тестовой базе на Postgres с вашими настройками, например,на УТ11 замерить закрытие месяца - два раза подряд ?
   ИТ директор
 
57 - 18.01.18 - 11:14
(54) ты много чего не видишь, но это не говорит что этого нет :)
   novichok79
 
58 - 18.01.18 - 11:17
(56) а что даст абстрактная цифра без объемов данных? да и сравнивать надо как минимум 2 показателя, а это значит что надо УТ 11.4 развернуть на MS SQL и сравнивать то же закрытие месяца.
   Фрэнки
 
59 - 18.01.18 - 11:20
(57) ну фантазируй дальше.
сходи в ветке Зависает база
обвини всех в кривых руках и призови всех к переходу на постгри :)

я же но про то, что где-то чего-то нет совсем, а про то, что оно не является абсолютным и необходимым для того, чтоб просто удовлетворить потребности 10 пользователей на типовой базе, в которой эти юзеры и данных огромных нагенерить не смогут, что дошло до вызова Спеца суперуровня
   ИТ директор
 
60 - 18.01.18 - 11:23
(59) чувак ты что курил, я несколько раз перечитал твой пост и ничего не понял
   ВикторП
 
61 - 18.01.18 - 11:28
(58) интересует, будет ли уменьшение времени . Поэтому подходит любая длительная обработка данных.
   MrCoffin
 
62 - 18.01.18 - 11:34
(40) Мне firebird больше нравится.
   skiller3000
 
63 - 18.01.18 - 11:41
(61) а то есть выполнить несколько закрытий подряд?
   don_Rumata
 
64 - 18.01.18 - 11:47
Благородные доны, а кто-нить может что-то сказать, про pg-storm, видеокарту и 1с? Работает ли эта фишка применительно к эске, есть ли ускорение или нет?
   novichok79
 
65 - 18.01.18 - 11:50
(61) соррян, оставил мисту у коллеги открытой на компе (63), и ответил с удаленки )))) вопрос именно в серии повторяющихся длительных операций, верно?
   ВикторП
 
66 - 18.01.18 - 12:27
(61) Да.
(65) Повтор одинаковых операций. Самое простое- Провести документ, потом еще раз провести документ , во второй раз проведется быстрее :) на MS SQL, на Postgresql у меня - нет.
А у вас как будет? Это интересует.
   don_Rumata
 
67 - 18.01.18 - 12:30
(66) У нас отчет о розничных продажах второй раз подряд проводится быстрее, чем первый
   ВикторП
 
68 - 18.01.18 - 12:46
можете написать время в первый раз, время во второй?
   ВикторП
 
69 - 18.01.18 - 12:47
можете поделиться конфигурационным файлом?
   don_Rumata
 
70 - 18.01.18 - 13:13
(68) в копии отчет проводится первый раз за 28 секунд, второй раз - за 23. Надо поискать что-то посложнее отчета, наверное
   don_Rumata
 
71 - 18.01.18 - 13:14
(69) могу, куда выслать?
   ВикторП
 
72 - 18.01.18 - 13:33
Можно сюда petryankin@rambler.ru
   novichok79
 
73 - 18.01.18 - 13:49
(71) да и мне если можно.
   novichok79
 
74 - 18.01.18 - 13:51
(71) мне на compofixer@gmail.com
   don_Rumata
 
75 - 18.01.18 - 13:57
(72)(73) отправил
   ВикторП
 
76 - 18.01.18 - 14:42
Спасибо, Алексей, получил, посмотрю
   novichok79
 
77 - 18.01.18 - 14:43
(75) мучас грасиас, ми эстимадо амиго
   trdm
 
78 - 18.01.18 - 14:48
Вроде мскуль кэширует планы запросов.
И перебрасывает часть данных в оперативку.
За счет этого и ускорение.
У постгреса кеширование работает?
   g00d
 
79 - 18.01.18 - 14:55
(16) вы просто не умеете его готовить
   novichok79
 
80 - 18.01.18 - 15:28
(79) поделитесь своим опытом, пожалуйста.
   g00d
 
81 - 18.01.18 - 15:51
(80) это так не работает :) рассказать на пальцах не получится.
Начните с того что перенесите постгрю в ее родную среду, в ОС Линукс. В идеале на отдельный сервер с хорошим процом и ввод\выводом.
   novichok79
 
82 - 19.01.18 - 13:25
(82) какой линух посоветуете для новичка в юниксовых утехах? у нас сервер и файлопомойка на одном компьютере.
   g00d
 
83 - 19.01.18 - 13:36
(82) Берите убунту, чрезвычайно много демоматериала для новичков
   Провинциальный 1сник
 
84 - 19.01.18 - 13:47
(78) У постгреса проблема не в отсутствии кэширования, а в плохом оптимизаторе (в характерных для 1с многоэтажных запросах к виртуальным таблицам). Поэтому он может миллионные таблицы начать соединять вложенными циклами, и кэширование практически ничего не ускорит..
   ERWINS
 
85 - 19.01.18 - 13:56
(84) было сравнение чисто оптимизаторов постгря и мсскл
9.1 и 20008 постгес выиграл.
   ИТ директор
 
86 - 19.01.18 - 13:56
(84) при наличии актуальной статистики (при включенном автофакууме она должна вроде как быть актуальной) всё там нормально с планами...я проверял, будет делать соединение хэшированием, таблицы 10 млн записей...
   ERWINS
 
87 - 19.01.18 - 13:56
не думаю что там появилось что то новое
   Провинциальный 1сник
 
88 - 19.01.18 - 14:04
(86) Угу.. сферический постгрес в вакууме выиграет у mssql) А в реальности минутами грузящие проц процессы постгреса - правда жизни.
   ИТ директор
 
89 - 19.01.18 - 14:05
(88) на винде процессы?
   Провинциальный 1сник
 
90 - 19.01.18 - 14:06
Речь не о синтетических тестах, а о том, что 1с любит джойны с подзапросами. И тут никакая статистика при вакууме не будет актуальной.
   ИТ директор
 
91 - 19.01.18 - 14:07
(90) на сиквеле те же яйца
   Провинциальный 1сник
 
92 - 19.01.18 - 14:09
(91) Он не настолько оптимист, поэтому в этих случаях чаще применяет сложные джойны, а не нестедлупы. А постгрес всегда предполагает, что вложенный запрос максимально селективен и возвращает маленький объем данных. Наверное это хороший стиль sql-программирования. Но в 1с не так.
   ИТ директор
 
93 - 19.01.18 - 14:10
(83) бубунту хуже всего работает с постгресом
   ИТ директор
 
94 - 19.01.18 - 14:14
(92) бред, всё намного сложнее, и упирается в низкоуровневую архитектуру, см. (16)
   Провинциальный 1сник
 
95 - 19.01.18 - 14:18
(94) Я одно время использовал постгрес с запрещенным нестедлупом в конф-файле - нормально, тупизны меньше было. То есть не было такого, что запрос зависал на несколько минут. Хотя, в среднем запросы выполнялись медленнее.
   g00d
 
96 - 19.01.18 - 15:19
(93) вы заблуждаетесь, это я как использующий 2 постгрес сервера в работе. один на центосе, второй на убунту.
разницы нет.
   ИТ директор
 
97 - 19.01.18 - 15:34
(96) на партнерском от чувака ссылка на доклад которого в (31), была такая инфа, он говорл что ставят только на центос
   ВикторП
 
98 - 19.01.18 - 15:40
Тут, оказывается , есть "движуха"

Доклад для ознакомления хорош . Вчера посмотрел, понравилось.
Он- докладчик - Антон Дорошкевич на инфостарте в моем топике проявился. Может, напишет про кэш.
   ИТ директор
 
99 - 19.01.18 - 15:43
(98) Виктор, а зачем вам, простите, понадобилось заниматься сисадминскими вещами?
   ВикторП
 
100 - 19.01.18 - 15:59
К эксперту начинаю готовиться. Без Postgres не получится :(

Сотка мне досталась
  1  2  3  4   

Список тем форума
Рекламное место пустует  Рекламное место пустует
Независимо от того, куда вы едете — это в гору и против ветра!
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует