ReSQL.ru
     
powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Сравнение скорости выполнения запроса на localhost и с соседнего сервера
25 сообщений из 29, страница 1 из 2
  1  все
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017827
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
В наличии 2 db сервера на centos с postgres 11 на обоих. Выполняю простейший запрос на localhost и на соседнем db2
Как советует данный разработчик
https://momjian.us/main/blogs/pgblog/2012.html#June_6_2012

Локальный запрос

Код: plsql
1.
2.
3.
4.
5.
$ time PGOPTIONS="-c log_min_duration_statement=0 \
  -c client_min_messages=log" psql -h localhost <<END
\timing
SELECT 1;
END




C сервера db2 на сервер db1

Код: plsql
1.
2.
3.
4.
5.
time PGOPTIONS="-c log_min_duration_statement=0 \
  -c client_min_messages=log" psql -h 192.168.12.1 –X <<END
\timing
SELECT 1;
END



Получаем такие данные на localhost
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Timing is on.
LOG:  duration: 0.186 ms  statement: SELECT 1;
 ?column?
----------
        1
(1 row)

Time: 0.299 ms

real    0m0.010s
user    0m0.004s
sys     0m0.005s



А вот такие при запросе c db2 на db1
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Timing is on.
LOG:  duration: 0.826 ms  statement: SELECT 1;
 ?column?
----------
        1
(1 row)

Time: 1.322 ms

real    0m4.529s
user    0m0.003s
sys     0m0.004s



Является ли это ненормальной разницей т.е Time: 1.322 ms > Time: 0.299 ms в таком % сотношении, не должно ли быть разницы в 10-20%? В какую сторону копать может кто что подскажет. Кто то может сравнить на своих серверах какие результаты получаются?
...
Рейтинг: 0 / 0
13.11.2020, 10:42
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017840
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
batong,

а вы сетевую задержку посмотрите между db1 и db2 и скорее всего станет все ясно.
(через ping например)

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
13.11.2020, 11:14
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017933
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
Maxim Boguk
batong,

а вы сетевую задержку посмотрите между db1
--
Maxim Boguk
пинг
rtt min/avg/max/mdev = 0.167/0.170/0.184/0.017 ms
задержка
лучшая поддержка PostgreSQL: dataegret.ru

Оба дб отдельные физические железки, а не блейд и не на вируталке. Так это все же большая разница в замере?
...
Рейтинг: 0 / 0
13.11.2020, 14:33
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017936
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.
...
Рейтинг: 0 / 0
13.11.2020, 14:36
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017954
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
batong

...Является ли это ненормальной разницей т.е Time: 1.322 ms > Time: 0.299 ms ....

1 ms? одна тысячная секунды? ненормально?

Я вообще не понимаю, что и зачем Вы измеряете. Это на уровне погрешности измерения.

Ну и да, для Ethernet порядок цифр в тысячи пакеты в секунду совершенно нормальный. AFAIK На 1 гигабите измерялки показывают latency и скорость максимум в 50 тыс. пакетов в секунду. Но это "сферические" пакеты, для нормальных round trip их надо в 10-50 раз делить. AFAIK

Хотите быстрее, тогда вместо Ethernet нужно покупать специализированное low latency оборудование. InifiniBand или напрямую коммутаторы PCI-e линий ))) и настраивать софт: прибивать прерывания к выделенным процессорным ядрам, задачи к выделенным ядрам и так далее )))

Но в обычной жизни это обычно не требуется. Очень мало людей, могут разницу в одну миллисекунду заметить.

Ну или нужно постараться, что бы они ее заметили (например бездумно в цикле генерировать сотни тысяч запросов по одной записи и удивляться, а почему так медленно работает)

AFAIK
...
Рейтинг: 0 / 0
13.11.2020, 15:13
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017956
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


https://www.mellanox.com/related-docs/whitepapers/HP_Mellanox_FSI Benchmarking Report for 10 & 40GbE.pdf

)))
...
Рейтинг: 0 / 0
13.11.2020, 15:18
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017969
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


А нафига вот в чем вопрос (т.е. чего вы пытаетесь добиться в итоге)?

Еще интересный вопрос а последующие запросы побыстрее не проходят?
Т.е. позапускайте c \timing on в тех же коннектах еще запросы такие же и посмотрите на время выполнения (меняется или нет).

Еще можно ssl отключить в конфиге базы приемника (он изрядный overhead дает на сетевом траффике).



--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
13.11.2020, 15:48
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017978
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mefman
Участник
Maxim Boguk
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


А нафига вот в чем вопрос (т.е. чего вы пытаетесь добиться в итоге)?

Еще интересный вопрос а последующие запросы побыстрее не проходят?
Т.е. позапускайте c \timing on в тех же коннектах еще запросы такие же и посмотрите на время выполнения (меняется или нет).

Еще можно ssl отключить в конфиге базы приемника (он изрядный overhead дает на сетевом траффике).



--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Точно. Засуньте ваш запрос в пгбенч и прогоните раз по 100. А вообще да, дебажить разницу в 1мс на абстрактных селектах - это из серии "когда коту делать нечего..."
...
Рейтинг: 0 / 0
13.11.2020, 15:59
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40017989
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
Maxim Boguk
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


А нафига вот в чем вопрос (т.е. чего вы пытаетесь добиться в итоге)?
--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Есть некий проект название не могу озвучивать. Cо схемой работы 2 видов: 1. сервер приложений jboss вынесен на отдельную железку от сервера db
2 все работает на 1м железе. Дополнительно в эту железку 1С выгружает данные. Начальные тесты показали что при расположении на 1м физическом сервере получаем, более быстрый вывод, реальных запросов и выгрузок в эту бд. На разделенном получаем условно от 30 до 50% потерь по времени на выгрузке, да и запросы друг на друга идут дольше. Процентное соотношение сохраняется даже при замене железок. Заказчики хотели бы довести потери на разделении сервера приложений от сервера бд до 20%, хотя судя по всему задача не решаема. Вот зачем это все потребовалось. Спасибо за любые коментарии.
...
Рейтинг: 0 / 0
13.11.2020, 16:09
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018006
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
Опишу поподробней
Схема1- сервер приложений jboss + postgres работают на 1м железе
Схема2- сервер postgres вынесен на отдельную железку
В jboss 1С выгружает данные.
Тесты в том числе и pgbench в 10 потоков, показали что при расположении на 1м физическом сервере получаем, более быстрый вывод, реальных запросов и выгрузок в эту бд.
На разделенном получаем условно от 30 до 50% потерь по времени. Заказчик говорит уменьшайте задержку в сети, настройками. Сами же пришли к выводу что все что можно сделано. Поэтому и хотелось бы услышать мнение со стороны.
...
Рейтинг: 0 / 0
13.11.2020, 16:28
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018032
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
batong
Опишу поподробней
Схема1- сервер приложений jboss + postgres работают на 1м железе
Схема2- сервер postgres вынесен на отдельную железку
В jboss 1С выгружает данные.
Тесты в том числе и pgbench в 10 потоков, показали что при расположении на 1м физическом сервере получаем, более быстрый вывод, реальных запросов и выгрузок в эту бд.
На разделенном получаем условно от 30 до 50% потерь по времени. Заказчик говорит уменьшайте задержку в сети, настройками. Сами же пришли к выводу что все что можно сделано. Поэтому и хотелось бы услышать мнение со стороны.


Скорее всего просто надо учиться в несколько потоков делать... потому что в одно соединение вы упретесь в network latency (и лучше чем "30 до 50% потерь по времени" сделать не получится скорее всего).
Т.е. если вы будете условно по 1000-10000 запросов гонять БЫСТРЫХ локально и через сеть - вот такая разница и будет и это нормально.
И никакой рост производительности сервера ничего не даст к сожалению.
Немного выиграете если сетку 10G поставите там latency заметно ниже будет все таки.
Можно еще 10gbit cross-over кабелем соединить 2 сервера напрямую (там еще ниже задержка будет).

А вообще - надо стараться задач решать не 1000+ быстрых запросов а 1-2-3 запросами к базе через вынос части логики в хранимки например или сложные запросы.
Тогда и эффекта сетевых задержек не будет.
хранимые процедуры не просто так придумали а для борьбы в том числе с сетевыми задержками на обмене база-сервер приложения.

PS: кстати у меня на одном из кластеров по лучше вот что имеем:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
local:
LOG:  duration: 0.113 ms  statement: SELECT 1;
 ?column? 
----------
        1
(1 row)

Time: 0.182 ms


remote:
LOG:  duration: 0.096 ms  statement: SELECT 1;
 ?column? 
----------
        1
(1 row)

Time: 0.213 ms
но там 10gbit сетка вдумчиво настроенная... и особо разницы нет где то 20%...

я все таки склоняюсь к тому что у вас там ssl=on и вы ssl handshake / encryption overhead ловите.
попробуйте ssl отключить на базах (смысла внутри защищенного периметра в ssl с базой никакого кроме тормозов лишних).


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
13.11.2020, 17:07
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018118
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
batong

На разделенном получаем условно от 30 до 50% потерь по времени.

Это не много. Если речь идет о разнице для __конечного__пользователя__ 5 миллисекунд или 55 миллисекунд, то конечному пользователю абсолютно на потерю 1 000 % должно быть глубоко пофиг. Оно все равно "быстро"

Если же софт написан так, что на один запрос __конечного_пользователя__ 100500 раз лезит в базу, то тогда задержка в 1 ms на запрос действительно приведет к 100500 ms задержки для конечного пользователя. Вот тут то может оказаться, что сложная отчетность (например формирование книги покупок продаж) вместо 1 часа начнет занимать 1:30 минут. Что будет печалить. А если еще окажется, что тайм аут на Web сервере стоит 60 минут, то вообще ж..., т.к. человек вообще своего отчета никогда не дождется )))

Т.е. в первом случае 1 000 % потерь - не важна
а во втором случае 50 % потерь - критично, вплоть до невозможности пользоваться системой

Настройками это не решается. Нужно нормально программы делать

batong

Заказчик говорит уменьшайте задержку в сети, настройками. Сами же пришли к выводу что все что можно сделано. Поэтому и хотелось бы услышать мнение со стороны.


AFAIK пару лет назад с похожей проблемой на подфорум Oracle приходил менеджер по продажам. У него все было намного хуже. На тестовом стенде (просто компьютер офисного класса), система работала нормально, поставили в серверную как было нарисовано по проекту. Сервер базы данных, сервер приложений.... Все стало работать в десятки,сотни раз медленнее. Заказчик подписывать акты приемки работ отказывался "Я купил сервера и оборудования на миллионы не для того, что бы медленнее работало. Отказываюсь подписывать акты."

Я даже ему оказал консультационные услуги, страшное слово за 45 тыс. рублей продал ))) setFetchSize ))) 45 / 12 = по 3 с половиной тысячи рублей за букву )))

Чем у них дело кончилось - не знаю. Т.к. общался только с ним, пока у него были проблемы. Потом один раз пообщался с его программистами, оставил им свой е-маил. Через пару дней человек позвонил, спросил номер моей карточки ))) чем закончились дела у его программистов - не знаю ))) трубку с моего номера они не брали, на мои письма не отвечали )))

В общем, ради интереса тогда разбирался, по итогам:

1) Latency на бытовом/офисных карточках настройками можно уменьшить раза в 2 __максимум__. Разница есть, но особого смысла нет.

2) могут помочь специализированные карточки. Ссылку на фирму уже приводил. Melanox Infiniband это принципиально другая технология, чем Ethernet. В первую очередь благодаря софту (передача идет без использования системного стека TCP/IP протокола, через специальная заглушку от Melanox).
Можно ли и насколько просто через них запустить PostgreSQL - не знаю
"Обычный Ethernet", пусть это даже 10 гбит Ethernet по оптике, low latency не позволит в принципе.

В подфоруме hardware обитал человек, который в России делает оборудование для сетей на основе прямого соединения PCI-e - PCI-e. Наверное можно найти его сообщения. И импортозамещение и работать будет быстрее )))

3) Если приложение настолько сильно зависит от сетевых задержек. Еп....ть программистов в хвост и в гриву. Если не получается самим, можно обратиться ко мне. Сдам в аренду своего кота. Их у меня двое, оба мальчика, этим самым занятием и в хвост и в гриву регулярно так занимаются, что спать по ночам не возможно )))

Возможно переписывать приложение. Если архитектор приложения страдал "хибернейтом головного мозга", возможно переписывать практически полностью.

инфляция, т.ч. консультационные услуги, продажа слов по буквам, аренда котов - от 100 тыс.
...
Рейтинг: 0 / 0
13.11.2020, 21:05
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018159
Dementyev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dementyev
Гость
[quot Leonid Kudryavtsev#22231725]
batong

Если приложение настолько сильно зависит от сетевых задержек. Еп....ть программистов в хвост и в гриву. Если не получается самим, можно обратиться ко мне. Сдам в аренду своего кота. Их у меня двое, оба мальчика, этим самым занятием и в хвост и в гриву регулярно так занимаются, что спать по ночам не возможно )))

Возможно переписывать приложение. Если архитектор приложения страдал "хибернейтом головного мозга", возможно переписывать практически полностью.

Я коллега, мне дали ссылку.
К сожалению не можем понять, с postgres только "знакомимся".
Есть взаимосвязь - разделение на 2 железки добавляет время обработки, и замеченная взаимосвязь на тестах - сильное увеличение времени обработки.
Что бы было понятно, возьмем самый тяжелый пример - полная перевыгрузка 1c -> Jbos:
- выгрузка всех справочников в пределах 1 железки (самой мощной из тестового стенда) 30 минут
- 2 такие же железки, в пределах 1 каталиста, гигабитного, 47 минут

Удалось понять пока следующее:
- локально все запросы идут через unix-сокеты, хотя в конфиге выглечены, (в CentOS произведены разработчиком изменения нам не известные)
- Включали дебаг5 лог, 90% запросов короткие (менее 1 мс), мб и архитектор не прав, но это не наш продукт, от нас исключительно внедрение.

На сами запросы мы не можем повлиять, мы можем заранее оптимизировать все под новую среду, сейчас идет выбор железа.
Мы и заказчик 1 организация, но разные отделы.

Мы только знакомимся с postgres, но не все из нас рождались DBA.

Насчет аренды кота - это тоже вопрос открытый и вполне рассматриваемый, все зависит от прайса и того, что сможете предложить.
...
Рейтинг: 0 / 0
13.11.2020, 23:26
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018165
Dementyev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dementyev
Гость
Параллельно решению вопросов выгрузки решаем еще другие вопросы.
Мы уже научись repmgr, сейчас учимся barman.
...
Рейтинг: 0 / 0
13.11.2020, 23:55
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018169
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Dementyev

Есть взаимосвязь - разделение на 2 железки добавляет время обработки, и замеченная взаимосвязь на тестах - сильное увеличение времени обработки.
Что бы было понятно, возьмем самый тяжелый пример - полная перевыгрузка 1c -> Jbos:
- выгрузка всех справочников в пределах 1 железки (самой мощной из тестового стенда) 30 минут
- 2 такие же железки, в пределах 1 каталиста, гигабитного, 47 минут

У меня в офисе, при "сферических" 50 тыс. пакетов в секунду, реальных JDBC Select'ов /Oracle/ в лучшем случае проходило в районе тысячи.

Можно чуть выкрутить сетевыми настройками (interrupt moderation на сетевой карте), можно чуть выкрутить прибиванием (afinity) процессов к процессорам - но это мертвому припарка.

Dementyev

- Включали дебаг5 лог, 90% запросов короткие (менее 1 мс), мб и архитектор не прав, но это не наш продукт, от нас исключительно внедрение.

На сами запросы мы не можем повлиять, мы можем заранее оптимизировать все под новую среду, сейчас идет выбор железа.
Мы и заказчик 1 организация, но разные отделы, между которыми коммерческие отношения.


Ну и что тут можно сделать?

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

Если требования по производительности софт не выдерживает - виноват разработчик
Если в документации по системе написано "сервер приложений и сервер БД рекомендовано размещать на одном компьютере" - то откуда взялась сеть

Dementyev

сейчас идет выбор железа.

AFAIK На Ethernet'е много не вытяните. Ethernet все равно на порядки медленнее loopback. Проблема даже не в самом Ethernet'е, а в сетевом протоколе OS и TCP/IP стеке. У loopback (localhost) во многих OS специальная заглушка - обмен с localhost идет не через полноценный TCP/IP стек, а через специально оптимизированный обрубок с минимумом функционала, но высокой скоростью.

Софт от Melanox'а как я понимаю (по докам, сам в глаза не видел) работает так-же. Для отдельного приложения вместо стандартного TCP/IP подпихивает реализацию от Melanox'а. Минимум функций, максимум скорости.

Dementyev

Мы только знакомимся с postgres

Postgres тут вообще не при чем.

Если есть задача массовой загрузки-выгрузки, то и решаться она должна пакетными средствами. А не по одной записи из 1С в PostgreSQL через 100500 прослоек передавать.

Туда сюда обратно, тебе и мне приятно ( C ) мурзилка
...
Рейтинг: 0 / 0
14.11.2020, 00:14
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018182
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Ссылка на старое обсуждение в разделе Hardware. Есть ссылки на продукты/карты/решения (для того времени).

https://www.sql.ru/forum/1129883-1/mozhno-li-zaderzhku-v-seti-1-gigabit-priblizit-k-teoreticheskoy
...
Рейтинг: 0 / 0
14.11.2020, 00:56
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018225
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НеофитSQL
Гость
batong,

Сравните передачу 10кб данных в одну сторону.

Локальный запрос: отдать буфер сокету - получить байты из сокета (одно копирование, не более).

Сетевой запрос:
- отдать буфер сокету
- поделить на пакеты (7)
- сочинить заголовки
- посчитать tcp xsums
- отдать карте по DMA
- загнать в провод
- получить 4 подтверждения что все дошло

- получить некоторые пакеты (4) по прерыванию
- скопировать по DMA
- проверить что пришли в нужном порядке
(Если нет, запросить пропавшие)
- проверить tcp xsum
- скопировать в буфер для состыковки
- передать неполный буфер
- повторить все шаги для ещё 3х пакетов.

Есть технологии сетевых карт (LSO и другие) которые ускоряют некоторые шаги, но сами шаги остаются.
Послать конверт соседу почтой занимает дольше, чем отнести его из одной комнаты в другую.
...
Рейтинг: 0 / 0
14.11.2020, 05:43
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018240
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Dementyev
Что бы было понятно, возьмем самый тяжелый пример - полная перевыгрузка 1c -> Jbos:
- выгрузка всех справочников в пределах 1 железки (самой мощной из тестового стенда) 30 минут
- 2 такие же железки, в пределах 1 каталиста, гигабитного, 47 минут

Удалось понять пока следующее:
- локально все запросы идут через unix-сокеты, хотя в конфиге выглечены, (в CentOS произведены разработчиком изменения нам не известные)
- Включали дебаг5 лог, 90% запросов короткие (менее 1 мс), мб и архитектор не прав, но это не наш продукт, от нас исключительно внедрение.

На сами запросы мы не можем повлиять, мы можем заранее оптимизировать все под новую среду, сейчас идет выбор железа.
Мы и заказчик 1 организация, но разные отделы.

Мы только знакомимся с postgres, но не все из нас рождались DBA.


Попробуйте ради интереса если уж закопались вариант с прямым cross-over кабелем между базой и приложением и выключенными ssl.
Все таки слишком большая у вас разница получается (хотя вполне в пределах разумного при работе с массой быстрых запросов всего 50% замедление).

PS: давно (и мне казалось всем) известно что производительность одно-малопользовательских корпоративных приложений написанных поверх ORM упирается не в скорость базы а в скорость (latency) сети между базой и приложением (потому что простые запросы на современном оборудовании отрабатывают быстрее чем ответ и запрос проходят по сетке).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
14.11.2020, 09:25
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018313
Dementyev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dementyev
Гость
Maxim Boguk

Попробуйте ради интереса если уж закопались вариант с прямым cross-over кабелем между базой и приложением и выключенными ssl.

Пробовали cross-over кабель, но не выключали ssl, разницы между соединением через каталист не заметили, получили те же 47 минут.

Прошу тапками не кидать за следующий вопрос, мы только учимся.
Если выключить ssl у postgres, это не повлияет на barman?
Пытаемся (обучаемся) использовать стратегию с rsync, ключи SSH же openssl
...
Рейтинг: 0 / 0
14.11.2020, 14:40
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018345
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Dementyev,

На барман это никак не повлияет.

Если и это не помогает - дальше включать полный лог запросов... с log line prefix с миллисекундам
и смотреть на разницу между локальным и удаленным запуском...

но как вам уже написали если у вас там логика сделана на миллионах быстрых запросов 30min vs 47min это нормальная разница и сильно ее сократить вряд ли получится.
особенно если кактой то гений (если это jdbc конечно) включил fetchSize и в итоге вместо 1 запроса к базе для получения данных выполняет 4ре (открыть курсор - выполнить - получить данные из курсора - закрыть курсор).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
14.11.2020, 17:22
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018713
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
Maxim Boguk,
Как понимаю ssl отключаем в параметрах postgres, ssl = off параметр был закомментирован, но по умолчанию и должно срабатывать ssl = off , так же в сборке отключен selinux.


После добавления в запрос explain analyze
Получаем увеличение времени . Это localhost
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
-bash-4.2$ time PGOPTIONS="-c log_min_duration_statement=0 \
>   -c client_min_messages=log" psql -h localhost <<END
> \timing
> explain analyze
> SELECT 1;
> END
Секундомер включён.
LOG:  duration: 0.269 ms  statement: explain analyze
SELECT 1;
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 0.051 ms
 Execution Time: 0.027 ms
(3 строки)

Время: 0,400 мс

real    0m0.005s
user    0m0.004s
sys     0m0.000s



Это с удаленного сервера
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
-bash-4.2$ time PGOPTIONS="-c log_min_duration_statement=0 \
>   -c client_min_messages=log" psql -h хх.хх.хх.хх -X<<END
> \timing
> explain analyze
> SELECT 1;
> END
Timing is on.
LOG:  duration: 1.095 ms  statement: explain analyze
SELECT 1;
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.003..0.003 rows=1 loops=1)
 Planning Time: 0.221 ms
 Execution Time: 0.121 ms
(3 rows)

Time: 1.450 ms

real    0m0.012s
user    0m0.001s
sys     0m0.003s



Результат выше получен на двух идентичных по железу серверах. подключенных через 1гб каталист либо cross-over нет отличий.

Меняю сервер db другой 2х процессорный, получаю результат, сеть все тот же 1гб через каталист.
localhost
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
>   -c client_min_messages=log" psql -h localhost <<END
> \timing
> explain analyze
> SELECT 1;
> END
Timing is on.
LOG:  duration: 0.625 ms  statement: explain analyze
SELECT 1;
                                     QUERY PLAN                                 
------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 0.124 ms
 Execution Time: 0.064 ms
(3 rows)

Time: 0.948 ms

real    0m0.015s
user    0m0.007s
sys     0m0.002s



Удаленный запрос
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
-bash-4.2$ time PGOPTIONS="-c log_min_duration_statement=0 \
>   -c client_min_messages=log" psql -h х.х.х.х -X<<END
> \timing
> explain analyze
> SELECT 1;
> END
Timing is on.
LOG:  duration: 0.611 ms  statement: explain analyze
SELECT 1;
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 0.119 ms
 Execution Time: 0.063 ms
(3 rows)

Time: 0.907 ms

real    0m0.008s
user    0m0.001s
sys     0m0.002s



Получаем даже выигрыш во времени. Настройка postgresql, основные параметры одинаковые, но с вариацией на оперативную память

Вот это и заставляет задуматься, по выбору оборудования. Связка db - app: для первоначального теста на 1процессорной сборке, оперативной памяти одинаково.
Связка db-app для второго теста: db 2х процессорный но по частотам слабее гораздо, больше оперативной памяти, сервер app как и в предыдущем тесте.

Правильно ли понимаю что в выборе оборудования все такие стоит сделать упор на количество ядер и для db сервера и для сервера приложений app? По мониторингу нагрузки упирания в производительность оборудования нет на обоих сборках.
...
Рейтинг: 0 / 0
16.11.2020, 11:30
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018749
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
batong,

а проверьте в каком режиме у вас процессоры ( /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ). Если не performance - то для такой мелкой задачи CPU может даже решить не выходить из powersave и продолжить работать, соответственно, на интересной частоте существенно ниже номинальной.
...
Рейтинг: 0 / 0
16.11.2020, 12:23
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018766
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
IMHO
batong

...
Получаем даже выигрыш во времени...
Правильно ли понимаю что в выборе оборудования все такие стоит сделать упор на количество ядер и для db сервера и для сервера приложений app? По мониторингу нагрузки упирания в производительность оборудования нет на обоих сборках.

IMHO сомнительный вывод
Некоректный тест.
"Если вдруг увидел люк, не волнуйся, это глюк" ( C ) народная мудрость

Нужно тестить в массе. Т.к. отдельные результаты измерений вполне могут быть +/- лапоть.
В данном случае лапоть оказался больше ))), чем разброс времени при измерениях, общий итог оказался отрицательным. IMHO

Связка db-app для второго теста: db 2х процессорный но по частотам слабее гораздо...
Код: sql
1.
2.
Время: 0,400 мс
Time: 0.948 ms



NUMA ?
...
Рейтинг: 0 / 0
16.11.2020, 12:54
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018848
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
Melkij
batong,

а проверьте в каком режиме у вас процессоры ( /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ). Если не performance - то для такой мелкой задачи CPU может даже решить не выходить из powersave и продолжить работать, соответственно, на интересной частоте существенно ниже номинальной.

Спасибо вы попали прямо в точку
по ядрам стоял режим
Код: plsql
1.
2.
[root@localhost ~]# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave


перевел ядра на cpu в режим performance
на серверах db и app по этой статье https://community.mellanox.com/s/article/how-to-set-cpu-scaling-governor-to-max-performance--scaling-governor-x
получил результаты очень обнадеживающие:
localhost
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
-bash-4.2$ time PGOPTIONS="-c log_min_duration_statement=0 \
>   -c client_min_messages=log" psql -h localhost -X<<END
> \timing
> explain analyze
> SELECT 1;
> END
Секундомер включён.
LOG:  duration:0.265 ms statement: explain analyze
SELECT 1;
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 0.046 ms
 Execution Time: 0.024 ms
(3 строки)

Время: 0,421 мс

real    0m0.005s
user    0m0.002s
sys     0m0.002s




с сервера приложений

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
-bash-4.2$ time PGOPTIONS="-c log_min_duration_statement=0 \
>   -c client_min_messages=log" psql -h 10.36.110.130 -X<<END
> \timing
> explain analyze
> SELECT 1;
> END
Timing is on.
LOG:  duration:0.214 ms  statement: explain analyze
SELECT 1;
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=4) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 0.040 ms
 Execution Time: 0.022 ms
(3 rows)

Time: 0.563 ms

real    0m0.006s
user    0m0.002s
sys     0m0.002s



На минимальном запросе результат уже радует, теперь будем проверять полноценную выгрузку в связку серверов. О результате отпишусь.
ПС. остается вопрос постоянная работа cpu в данном режиме чем обернется в будущем?
...
Рейтинг: 0 / 0
16.11.2020, 14:33
| Ответить | Цитировать | Написать  
Сравнение скорости выполнения запроса на localhost и с соседнего сервера
    #40018874
batong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
batong
Гость
Leonid Kudryavtsev
IMHO
NUMA ?

Да возможно вы тоже правы. В загрузчике она не выключена. Сравню уже в отдельном замере, вернув режим работ процессоров powersave. Огромное спасибо.
...
Рейтинг: 0 / 0
16.11.2020, 14:56
| Ответить | Цитировать | Написать  
25 сообщений из 29, страница 1 из 2
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Сравнение скорости выполнения запроса на localhost и с соседнего сервера
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=40017978&tid=1994367]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 160ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 48ms
get tp. blocked users:
 1ms
others: 14ms
total:  261ms
созд. / загр.: 261ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]