Короткое нагрузочное тестирование PostgreSQL простыми запросами

10.12.18

База данных - HighLoad оптимизация

Короткое нагрузочное тестирование PostgreSQL простыми запросами. Прилагаются результаты в файлах pgBadger и perfmon.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Тест PostgreSQL:
.rar 2,95Mb
1
1 Скачать (1 SM) Купить за 1 850 руб.
Тест PostgreSQL:
.rar 2,95Mb
0
0 Скачать (3 SM) Купить за 2 450 руб.

Предисловие

Несколько лет назад мне в руки попала «Настольная книга эксперта» Евгения Филиппова. Оказалось, что запросы можно писать лучше, заставить программу 1С работать быстрее. С тех пор я подмечал интересные статьи, идеи, доклады. Один из них – доклад Виктора Богачева http://v8.1c.ru/expert/cts/expert.htm о работе в ОАО «Деловые линии». Работа хорошо документирована в рамках проекта ЦКТП и широко освещалась в медиа, в том числе на Инфостарте.

Статья //infostart.ru/public/850217/ - попытка реконструировать ситуацию из доклада с использованием MS SQL 2012. В ней можно найти краткий конспект доклада. Продолжение статьи с использованием PostgreSQL было неизбежно. Итак, мы планируем запускать тестовые задачи в связке 1С + PostgreSQL и наблюдать за поведением хоста и СУБД.

Выбор тестовых задач

Будем использовать 1С + PostgreSQL + Windows, это достаточно популярное решение. Пора развенчать миф о недоступности PostgreSQL.

 
 Даешь PostgreSQL в народные массы !

 

Для создания нагрузки, будем запускать ФоновыеЗадания.Выполнить() несколько клиентов. Запросы в цикле. Задача - оценить пиковую нагрузку. В основном, тестовые задачи будут те же, что и в статье //infostart.ru/public/850217/. Это позволит сравнить результаты работы различных СУБД с одной конфигурацией 1С. Выгрузка базы данных прилагается, кто захочет – сможет повторить.

  1. ВЫБРАТЬ 1+1 КАК Поле2
  2. ВЫБРАТЬ Тестирование.Код ИЗ Справочник.Тестирование  КАК Тестирование
  3. ВЫБРАТЬ 1+1 КАК Поле2 ПОМЕСТИТЬ ВремТаблица
  4. ВЫБРАТЬ 1+1 КАК Поле2 ПОМЕСТИТЬ ВремТаблица ИНДЕКСИРОВАТЬ ПО Поле2
  5. Полное соединение
  6. Левое соединение
  7. Декартово произведение

Также посмотрим поведение СУБД PostgreSQL для разных случаев:

  1. Настройка конфигурации «из коробки».
  2. Получение в технологическом журнале плана запросов
  3. Проверим влияние параметра конфигурации  fsync по статье https://its.1c.ru/db/metod8dev#content:5825:hdoc, https://its.1c.ru/db/metod8dev#content:1576:hdoc
  4. Сравнение с MS SQL 2012

Влияние параметров конфигурации, связанных с Checkpoint и транзакциями, проверять не будем.

Подготовительная работа

ОС - Windows 10, 64 бит, жесткий диск SSD, 16 Гб RAM, процессор i3-6100 @ 3.7 GHz (два ядра), гигабитная сеть.

Скачал и установил программы:

1С:Предприятие 8.3 (8.3.11.3034)

Адрес https://releases.1c.ru ссылка PostgreSQL, версия 9.6.7-1.1C каталог установки C:\Program Files\PostgreSQL\9.6.7-1.1C

В состав пакета входит графическая оболочка pgAdmin версия 4. Есть более свежая версия СУБД, но она требует 1С версия 8.3.13.

Для использования pgBadger настроим файл postgresql.conf по статье http://pgcookbook.ru/article/pgbadger.html (аналогичная информация есть на ИТС)

log_line_prefix = '%t [%p]: [%l-1] '

формат логов

log_duration = on

Включает логирование запросов

log_min_duration_statement = 0

минимальное время миллисекунд выполнения запроса. В документации указано =0.

Если установить log_min_duration_statement = -1, то сообщения об ошибке нет, но статистика будет собираться неверно, отражая заоблачные значения производительности.

Адрес http://strawberryperl.com/ ссылка Strawberry Perl 5.28.0.1 (64bit) каталог установки C:\Strawberry

Среда Perl нужна для исполнения скрипта pgBadger.

Адрес https://github.com/darold/pgbadger/releases  ссылка pgbadger-10.1.tar.gz каталог установки C:\pgbadger-10.1

Командный файл для запуска скрипта pgBadger из каталога временных файлов C:\Users\vasiliev_ng\temp автоматически формируется 1С при запуске теста, включает одну минуту журнала, которая содержит результаты последнего теста, например:

xcopy "C:\Program Files\PostgreSQL\9.6.7-1.1C\data\pg_log\*.*" "C:\Users\vasiliev_ng\temp\" /Y

C:\Strawberry\perl\bin\perl c:\pgbadger-10.1\pgbadger -a 1 -b "2018-11-30 22:38:46" -e "2018-11-30 22:40:26" --anonymize C:\Users\vasiliev_ng\temp\postgresql-Fri.log

Копировать лог СУБД в каталог C:\Users\vasiliev_ng\temp, запустить perl с указанием скрипта, параметры, файл логов для анализа. В ответ будет создан новый файл Out.html. Таблицу параметров из документации перевел на русский, файл perevedi.xlsx в приложении. Скрипт формируется и исполняется 1С (Выгрузка базы данных прилагается).

 
 Тест является элементом справочника.

Общая информация о тестировании.

Информацию о состоянии хоста будем получать средствами perfmon. Показатели выбираем в соответствии со статьей https://its.1c.ru/db/metod8dev#content:2923:hdoc: очередь к процессору, очередь к диску, сетевой интерфейс - бит всего. Оперативную память проверял – почти не расходуется. Сетевой интерфейс бывает загружен несущественно (до 5%). Очередь к диску практически не изменяется, добавил показатель «Скорость обмена с диском байт/секунду». Файлы шаблона сборщиков данных прилагаются.

Информацию о состоянии СУБД PostgreSQL будем получать из самой СУБД, с использованием pgBadger. Этот бесплатный, но мощный инструмент СУБД PostgreSQL до сих пор упоминался в публикациях Инфостарта два раза, рассмотрим его подробнее.

Все тесты запускал много раз, добиваясь устойчивых, прозрачных результатов. Вначале картина была неполная: на сервере СУБД количество запросов в секунду не росло выше определенного предела, упиралось в потолок, а свободные ресурсы были. После переноса кластера 1С на этот же хост стало видно узкое место: процесс rphost при таких тестах потребляет значительные ресурсы ЦП, а сервер кластера 1С был недостаточно производительным. Выбрал более мощный сервер для кластера 1С.

 
 распределение памяти, если сервер кластера и СУБД совместить.

Для каждого фонового задания запускается отдельный экземпляр PostgreSQL. Количество сеансов и циклов в тесте подбирал так, чтобы загрузка процессора была максимальной в течение одной минуты. Такие тесты пригодятся, чтобы сделать поверхностные выводы, но настоящие нагрузочные тесты намного сложнее и дольше.

1. Настройка конфигурации «из коробки»

 
 Результаты тестирования

Номер запроса

Клиенты

Циклы

Пик, тысяч запросов в секунду

Файлы pgBadger,

Perfmon

1

90

9999

27

 

Simply_081512

2

90

9999

20

 

RefQuery_081548

Простейшие запросы должны показывать большее число запросов в пике по сравнению с более сложными запросами. Например, если в простейший Запрос 1 просто добавить текстовое поле, пик упадет на 5%. В этом смысле видно предел быстродействия.

Когда выполнял Запрос 1, то получил ошибку «FATAL: sorry, too many clients already». В логе pgBadger отображается на закладке «Events». Проверил конфигурацию: max_connections = 100, shared_buffers = 128MB. Изменять не стал )).

 
 результаты тестирования

3

26

9999

6,9

TempTable_091216

4

26

9999

5,4

IndexTable_091210

Запросы №3,4 создают временную таблицу (индекс), записывают данные на диск. Самые медленные запросы в этих опытах – работа с временными таблицами и индексами:

  • DROP TABLE IF EXISTS tt1 CASCADE; CREATE TEMPORARY TABLE tt1
  • INSERT INTO pg_temp.tt1
  • CREATE INDEX
  • DROP INDEX IF EXISTS

Распределение запросов по типам:

  • Запрос № 3 select 33%, insert 33%
  • Запрос № 4 select 17%, insert 17%, DDL 50%

5

9

3333

2.4

FullJoin_081628

6

9

3333

5.6

LeftJoin_081724

7

9

3333

5.6

Decart_081733

Здесь используем, что запросы

  • ВЫБРАТЬ * ИЗ ВремТаблица КАК ВремТаблица1 ПОЛНОЕ СОЕДИНЕНИЕ ВремТаблица КАК ВремТаблица2 ПО ИСТИНА
  • ВЫБРАТЬ * ИЗ ВремТаблица КАК ВремТаблица1 ЛЕВОЕ СОЕДИНЕНИЕ ВремТаблица КАК ВремТаблица2 ПО ИСТИНА
  • ВЫБРАТЬ * ИЗ ВремТаблица КАК ВремТаблица1, ВремТаблица КАК ВремТаблица2

Дают одинаковый результат (если в декартовом произведении отсутствует null). Однако СУБД интерпретирует их по-разному.

В списке самых медленных запросов видим запросы работы с временными таблицами и запрос типа  SELECT … FROM … INNER JOIN  … ON  …  INNER  … ON  …  INNER JOIN  … ON  … WHERE  … UNION ALL SELECT  … INNER JOIN  …  ON  … INNER JOIN  …  ON  … WHERE NOT (EXISTS ( SELECT  … FROM …

Откуда становится ясно, как именно PosqreSQL вычисляет полное соединение. Кстати, один из вариантов замены полного соединения рассмотрен в статье  //infostart.ru/public/794859/ с математическим доказательством эквивалентности запросов методом математической индукции.

В опытах 5-7 оператор полного соединения на ВремТаблица (625 строк) дает скорость в два раза меньше, чем операторы левого и декартового соединения в эквивалентных запросах. Причем, разница в скорости может возрастать нелинейно с ростом количества строк. Однако, не нужно бросаться переписывать все операторы полного соединения для использования PostgeSQL. Как указал Е. Филиппов, «работать нужно с существующими проблемами».

2. Конфигурация «из коробки» после включения ТЖ.

Включим ТЖ: сбор планов, SDBL, DBPOSTGRS. Файл logcfg.xml прилагается. Результаты в таблице.

Номер запроса

Клиенты

Циклы

Пик,  тысяч запросов в секунду

Файлы pgBadger,

Perfmon

7

9

3333

5,7

Decart_081748

Численное значение пиков практически не поменялось, но в списке самых медленных запросов появились запросы типа EXPLAIN ANALYSE SELECT.., количество которых равно количеству «целевых» запросов. Фактически, каждый запрос выполняется два раза – один раз дополнительно, чтобы получить план запроса. Можно сказать, что «целевых» запросов стало в два раза меньше.

3. Изменяем конфигурацию.

Запросы 3,4 работали с временными таблицами, использовали жесткий диск. Проведем эксперимент – установим параметр fsync  = off ( По умолчанию fsync = on ). В приложении bat-файл, который останавливает службу Postgres, копирует измененный config и запускает службу. Выполним нагрузочный тест.

Номер запроса

Клиенты

Циклы

Пик,  тысяч запросов в секунду

Файлы pgBadger,

Perfmon

3

26

9999

7,2

TempTable_091233

4

26

9999

5,7

IndexTable_091226

В обоих опытах значения пиков запросов больше на 4-6 процентов. Чем активнее запрос работает с диском, тем больше он чувствителен к параметру fsync. Дисковые операции стали выполняться несколько быстрее, но вероятность io ошибки тоже выросла.

4. Сравнение PostreSQL 9.6 и MS SQL 2012

Создадим базу данных на MS SQL 2012, используя ту же базу 1С (выгрузка прилагается).

Номер запроса

Клиенты

Циклы

Пик,  тысяч запросов в секунду

ФайлPerfmon

1

90

9999

21,3

Simply_091647

2

90

9999

17,3

RefQuery_090841

Значения ниже, чем в опытах PostgreSQL, но есть важный нюанс. Загрузка процессора существенно ниже, чем в первых опытах и не понятно, чем вызвано ограничение числа запросов. Конфигурация серверов не изменялась, но возможно MS SQL работает с сервером кластера активнее и сервер кластера опять стал узким местом.

3

39

9999

11.7

TempTable_090636

4

39

3333

11

IndexTable_090817

В опытах 3,4 появились характерные блокировки Latch. При этом есть корреляция между ростом числа блокировок и падением числа запросов в секунду. Возможно, это основной фактор, мешающий росту. Загрузка процессора доходит до 70%. Это существенное значение, но очередь меньше 2 на ядро. В опытах PostgreSQL загрузка доходила до 90%, очередь выше 2 на ядро.

6

27

3333

6.8

LeftJoin_090830

Значения сопоставимые с PostrgeSQL. Полное соединение и декартово произведение не тестировал.

Заключение

В публикации проведена серия тестов, результаты полностью открыты для Сообщества. В целом, PostgreSQL произвел на меня положительное впечатление. Есть ощущение развития и комфорта. Инструмент pgBadger - просто бомба, поэтому использовал его как логотип статьи. Хочется пожелать успехов pg-разработчикам.

Послесловие

Кстати, мне удалось получить ответ от Виктора Богачева о использовании PostgreSQL в ОАО «Деловые линии»:

- В докладе вы сказали, что рассматривали две СУБД: MS SQL и DB2 ? Скажите, рассматривали ли PostgreSQL и если нет - то почему ?

- На тот момент Postgres менее активно продвигался в том числе фирмой «1С» …

Отдельное спасибо техподдержке info@postgrespro.ru Постгрес Профессиональный https://postgrespro.ru за оперативность. Они действительно помогают. Тикет OTRS 2018112355000121 можно закрывать.

 

*********

 

С 4 по 6 февраля 2019 года в стенах Московского государственного университета состоится конференция по PostgreSQL – PGConf.Russia 2019. Ежегодно она собирает более 500 разработчиков, администраторов баз данных и IT-менеджеров для обмена опытом и профессионального общения.

На этот раз PGConf.Russia будет особенной. Инфостарт совместно с Postgres Pro организует на конференции секцию «Postgres+1C». Мы приглашаем участников сообщества посетить PGConf и даже выступить в качестве докладчика.

Нагрузочное тестирование СУБД PostgreSQL pgBadger

См. также

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    8706    Evg-Lylyk    61    

43

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    4869    spyke    28    

49

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    7234    vasilev2015    20    

42

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    11815    227    ZAOSTG    76    

115

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    5251    glassman    17    

40

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    12357    doom2good    49    

71
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. vasilev2015 2718 10.12.18 12:01 Сейчас в теме
Файлы одинаковые, только цена разная. Выбирайте. Маркетинг )).
2. a.doroshkevich 1428 10.12.18 15:31 Сейчас в теме
Классное исследование и хорошая статья!
Прям не поленились)

Я правильно понял что в запросы 3,4 на MS SQL отработали в 2 раза быстрее?

И ещё вопрос, в конфигурации PostgreSQL параметр online_analyze.enable чему равен?
3. vasilev2015 2718 10.12.18 15:54 Сейчас в теме
(2) Здравствуйте !

online_analyze.enable = off
Из коробки, не менял.

Результаты сравнения мне трудно интерпретировать.
Такое ощущение, что для MS SQL узким местом стал сервер кластера 1С,
и если его устранить, то производительность вырастет. Буду еще смотреть.
4. a.doroshkevich 1428 10.12.18 16:14 Сейчас в теме
Если есть возможность, то
online_analyze.enable = on

Перед тестирование перечитать настройки PG и провести Vacuum + analyze всей базы
5. a.doroshkevich 1428 10.12.18 17:37 Сейчас в теме
И ещё, раз это PG на Windows, то выполните те же тесты на версии 10.5 (на сайте 1С уже есть)
6. vasilev2015 2718 10.12.18 22:06 Сейчас в теме
(5) Спасибо за подсказку, сделаю на выходных. Будет еще одна сравнительная таблица.
14. vasilev2015 2718 13.12.18 09:36 Сейчас в теме
(5) Здравствуйте, Антон ! Может, выгоднее сделать дополнение по версии 9.6 Enterprise, а не по 10, как Вы считаете ? Хочу еще дополнить тесты, например запросом который сильно загружает жесткий диск, включить в тестирование параметры кроме fsync. Можете что-то посоветовать ?
15. a.doroshkevich 1428 13.12.18 11:40 Сейчас в теме
(14)
С Enterprise стоит сравнивать только если использовать его фишки быстродействия, такие как сжатие данных, а это актуально только на больших объёмах данных.

Тест с запросом сильно загружающим диск - по идее это означает что запрос неверный и БД не обязана это корректно отрабатывать.
Я люблю сравнивать рабочую нагрузку, так как потом в жизни именно она, а не синтетика.

Так что я бы всё таки протестировал версию 10 на Windows, с тем же самым профилем нагрузки что в статье.
16. vasilev2015 2718 13.12.18 12:33 Сейчас в теме
(15) Попробовал запустить тест на PostgreSQL 10. Но для него нужно использовать 8.3.13 не только на моей машине, но и на серверах кластера 1С. А это продуктивный контур )). Я не смог убедить своих коллег )).
17. a.doroshkevich 1428 13.12.18 17:24 Сейчас в теме
(16)жаль. Но
Что мешает поставить на серверах 3.13 отдельной службой никак не затрагивая рабочий контур?
7. capitan 2492 11.12.18 14:08 Сейчас в теме
Очень странно что мелкий и мягкий сервер 2012 показал ниже результаты.
Не сочтите пиаром - но если стенд не разобрали - померяйте отдельно сервера БД без 1С ?
https://infostart.ru/public/913958/
8. a.doroshkevich 1428 11.12.18 18:00 Сейчас в теме
(7)а смысл отдельно измерять?
С 1С же потом работать через сервер 1С, а не напрямую.
9. capitan 2492 11.12.18 18:30 Сейчас в теме
(8)Смысл как раз есть - понять где узкое место.
10. vasilev2015 2718 12.12.18 09:34 Сейчас в теме
(7) Здравствуйте, Андрей !

Посмотрел тест HammerDB - прикольная штука. Фото прилагаю, 117 тысяч tpm - соответствуют моему процессору i3. Как я понял, HammerDB измеряет количество транзакций, а у меня в статье пик количества запросов, но возможно эти результаты коррелируют. Для поиска узких мест предпочитаю замерять процент загрузки и очередь (perfmon). В опытах с PostgreSQL это сработало полностью, с остальным пока разбираюсь. Время ограничено.
Добавил вашу статью в избранное символом звездочка. Не-намек на не-пиар. :-)
Прикрепленные файлы:
11. capitan 2492 12.12.18 10:28 Сейчас в теме
(10)Я то имел в виду следующее:
У вас получились результаты что Постгри делает Микрососфт на их же сервере.
Это несколько загадочно, а для Билла Гейтса так вообще наверное обидно )
Да не несколько, а очень загадочно
Но у вас связка - сервер - 1С - сервер БД
Тестом HammerDB вы убираете из это связки 1С и меряете сервер - сервер БД
Т.е. надо еще и второй сервер БД сервер HammerDB померять и сравнить.
Тогда будет понятно - это из за 1С или нет.
Что касается процессора i3 - то у меня нет по нему данных tpm, но на правду похоже
12. vasilev2015 2718 12.12.18 11:08 Сейчас в теме
(11) Нет, я бы не стал так интерпретировать. На простейшем запросе Постгрес делает 27 тысяч, МС делает 20 тысяч, но при этом Постгрес упирается в процессор (свыше 90%), а МС демонстрирует свободные ресурсы (50%). Я не могу дотянуться до серверов кластера и замерить их производительность. Вообще, я зарекся сравнивать Постгрес и МС. Они просто разные. Тем более что здесь - Постгрес на Windows. Понимаю, что Вам не видно файлов perfmon. Поставлю фото экрана (принтскрин) в статью, чтобы подробнее.
13. capitan 2492 12.12.18 11:31 Сейчас в теме
(12)
МС демонстрирует свободные ресурсы (50%)
вот это то и подозрительно.
И как раз если это вылечить то все встанет на свои места МС побьет Постгри
18. user1007495 22.01.19 19:58 Сейчас в теме
Добрый день.
Спасибо за статью.
Может быть кто-то сможет помочь - ну никак не удаётся заставить pgbadger работать под Windows (пробовал Windows Server 2012 R2, как в доменной среде так и отдельно на сервере, не введённом в домен, также пробовал на клиентском компьютере под Win7 x64, ).

Устанавливаю Strawberry Perl (уже попробовал разные версии и разрядности), переменная среды "perl" прописывается, команды выполнять могу (perl -v работает)
Скачиваю pgBadger (версия 10.2), прочитал в интернете, что сначала нужно выполнить Makefile.PL из каталога pgbadger (впрочем, пробовал и до выполнения Makefile.PL и после).
Пробую работать с pgbadger из-под perl: в cmd перехожу в каталог установки pgbadger, выполняю "perl pgbadger -help" или "perl pgbadger -V". Всё работает, справка показывается, версию вижу.
Пробую указывать лог postges'a - выполнение зависает, прогресса нет, ожидание ничего не даёт. Пробую указывать ключ -v для pgbadger, чтобы видеть подробный вывод. Вижу что, процесс зависает на одном из двух этапов (картинка в аттаче). Висит, пока не прервёшь принудительно.

Форматы лога пробовал разные (csv уже в конце). Если лог пустой - pgbadger это видит, понимает и сообщает.
Если нет прав - также говорит Permission Denied. Пробовал явно указывать путь выходного файла в каталог, куда точно у всех есть права. Эффекта ноль.
Прочитал в интернете, что в пути к логу в cmd не должно быть обратных слешей, везде писать прямые (так как интерпретатор перл может воспринимать обратный слеш с идущим следом символом как элемент регулярного выражения, что приведёт к ошибке выполнения скрипта). Указывал по-всякому, ноль эффекта.

Ну и самое главное, лог - точно пригоден для парсинга. Проверил всю систему под Linux (CentOS 7), все работает отлично, выходной html-файл информативен, всё круто в общем. Скрин в аттаче.
Затевать переброску логов между серверами не очень хочется, тем более, если у народа работет и под виндой всё.
В чём может быть проблема ещё? Уже голову сломал
Прикрепленные файлы:
19. vasilev2015 2718 22.01.19 21:54 Сейчас в теме
(18) Здравствуйте !

Единственная доступная мне машина содержит Windows )).
Все, что сделал - подробно записал - сможете повторить.
Makefile.PL я не запускал, но поправил файл pgbadger в текстовом редакторе - иначе выходила ошибка.
Вы pgbadger скачивали с того же ресурса, как в статье ? (Он должен быть около 1 Мб)
Обязательно настройте файл postgresql.conf - Вы про это не указали.
Размер логов postgres должен быть около 100 Мб - у меня это 10 минут работы.
20. user1007495 23.01.19 09:57 Сейчас в теме
(19) Добрый день. Спасибо за ответ.

Все, что сделал - подробно записал - сможете повторить.
Простите, не понял, записали где? В статье?

Сам pgbadger да, скачал по ссылке с гитхаба. Дело в том, что я беру один и тот же архив со скриптом pgbadger и один и тот же файл лога postgresql. Копирую это всё на разные сервера. В Linux парсится, в Windows - нет.
postgresql.conf настроен. В лог всё пишется в соответствии со структурой указанной в log_line_prefix. У Вас log_destination как настроен? У меня = 'stderr'. Размер логов postgres, я думаю, может быть разным. Я беру файл логов за период работы около часа, поэтому у меня он меньше - в районе 10МБ. Соответственно, обрабатывается быстрее. Но, повторюсь, в Linux он обрабатывается нормально.

поправил файл pgbadger в текстовом редакторе - иначе выходила ошибка

А можете подсказать, что конкретно поправили?
21. vasilev2015 2718 23.01.19 10:19 Сейчас в теме
(20) Здравствуйте !

я когда скачивал pgBadger, долго выбирал. Мне кажется, для Windows он другой. Посмотрите ссылку в статье. Файл pgBadger должен "весить" 1 Мб.

Ошибку в текстовом файле не помню. Если у Вас появится - скажите.
22. user1007495 23.01.19 11:09 Сейчас в теме
(21)вау, получилось.
Всё-таки Вы мне помогли.
Скачал предыдущий pgbadger (10.1), в общем, как у Вас в статье и всё сходу полетело (скрин во вложении). На 10.2, выходит, на Linux работает хорошо, на Windows никак. Кстати, на одном из Linux-серверов у нас очень старый Perl (5.8.8), в нём pgbadger тоже не отрабатывает - сыпет ошибки.

В общем, вывод - крайне внимательно относиться к версиям Perl и самого скрипта pgBadger.
Рабочая конфигурация:
-Windows 7 x64
-perl 5.28.1 built for MSWin32-x64
-pgBadger 10.1

Ну и стоит ещё упомянуть о таких интересных ключах pgbadger как -I ("И" - инкремент) в комбинации с -O (--outdir path).
Если при выполнении указывать одну и ту же выходную директорию, указывая при этом ключ "инкрементный режим", то pgbadger создаст в этой выходной директории структуру сайта и стартовую страничку index.html, по запуску которой будет открываться календарь с возможностью выбрать день и посмотреть отчёт по статистике postgres именно по этому дню.
При этом новые дни будут добавляться с каждым выполнение скрипта.

Спасибо.
Прикрепленные файлы:
Оставьте свое сообщение