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

10.12.18

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

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

Скачать файлы

Наименование Файл Версия Размер
Тест PostgreSQL:
.rar 2,95Mb
1
.rar 2,95Mb 1 Скачать
Тест PostgreSQL:
.rar 2,95Mb
0
.rar 2,95Mb Скачать

Предисловие

Несколько лет назад мне в руки попала «Настольная книга эксперта» Евгения Филиппова. Оказалось, что запросы можно писать лучше, заставить программу 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 Конфигурации 1cv8 Бесплатно (free)

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

13.03.2024    2976    spyke    26    

42

Быстродействие типовой 1С

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

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

13.03.2024    5107    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

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

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

1 стартмани

15.02.2024    7634    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

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

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

09.01.2024    5977    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8868    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5105    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16184    skovpin_sa    14    

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

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

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

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

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

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

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

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

Посмотрел тест HammerDB - прикольная штука. Фото прилагаю, 117 тысяч tpm - соответствуют моему процессору i3. Как я понял, HammerDB измеряет количество транзакций, а у меня в статье пик количества запросов, но возможно эти результаты коррелируют. Для поиска узких мест предпочитаю замерять процент загрузки и очередь (perfmon). В опытах с PostgreSQL это сработало полностью, с остальным пока разбираюсь. Время ограничено.
Добавил вашу статью в избранное символом звездочка. Не-намек на не-пиар. :-)
Прикрепленные файлы:
11. capitan 2466 12.12.18 10:28 Сейчас в теме
(10)Я то имел в виду следующее:
У вас получились результаты что Постгри делает Микрососфт на их же сервере.
Это несколько загадочно, а для Билла Гейтса так вообще наверное обидно )
Да не несколько, а очень загадочно
Но у вас связка - сервер - 1С - сервер БД
Тестом HammerDB вы убираете из это связки 1С и меряете сервер - сервер БД
Т.е. надо еще и второй сервер БД сервер HammerDB померять и сравнить.
Тогда будет понятно - это из за 1С или нет.
Что касается процессора i3 - то у меня нет по нему данных tpm, но на правду похоже
12. vasilev2015 2686 12.12.18 11:08 Сейчас в теме
(11) Нет, я бы не стал так интерпретировать. На простейшем запросе Постгрес делает 27 тысяч, МС делает 20 тысяч, но при этом Постгрес упирается в процессор (свыше 90%), а МС демонстрирует свободные ресурсы (50%). Я не могу дотянуться до серверов кластера и замерить их производительность. Вообще, я зарекся сравнивать Постгрес и МС. Они просто разные. Тем более что здесь - Постгрес на Windows. Понимаю, что Вам не видно файлов perfmon. Поставлю фото экрана (принтскрин) в статью, чтобы подробнее.
13. capitan 2466 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 2686 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 2686 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 именно по этому дню.
При этом новые дни будут добавляться с каждым выполнение скрипта.

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