Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
В наличии 2 db сервера на centos с postgres 11 на обоих. Выполняю простейший запрос на localhost и на соседнем db2
Как советует данный разработчик
https://momjian.us/main/blogs/pgblog/2012.html#June_6_2012

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

$ time PGOPTIONS="-c log_min_duration_statement=0 \
  -c client_min_messages=log" psql -h localhost <<END
\timing
SELECT 1;
END



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

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
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
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%? В какую сторону копать может кто что подскажет. Кто то может сравнить на своих серверах какие результаты получаются?

Сообщение было отредактировано: 13 ноя 20, 10:42
13 ноя 20, 10:42    [22231273]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
batong,

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
13 ноя 20, 11:14    [22231295]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Maxim Boguk
batong,

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

Оба дб отдельные физические железки, а не блейд и не на вируталке. Так это все же большая разница в замере?

К сообщению приложен файл. Размер - 36Kb
13 ноя 20, 14:33    [22231433]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.

Сообщение было отредактировано: 13 ноя 20, 14:31
13 ноя 20, 14:36    [22231436]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
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
13 ноя 20, 15:13    [22231461]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


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

)))
13 ноя 20, 15:18    [22231463]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


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

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

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



--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
13 ноя 20, 15:48    [22231482]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
mefman
Member

Откуда:
Сообщений: 3164
Maxim Boguk
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


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

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

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



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

Точно. Засуньте ваш запрос в пгбенч и прогоните раз по 100. А вообще да, дебажить разницу в 1мс на абстрактных селектах - это из серии "когда коту делать нечего..."
13 ноя 20, 15:59    [22231494]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Maxim Boguk
batong
Многие ссылаются на сеть и задержки, но кто то бы привел пример оптимальной задержки для минимального запроса и на каком оборудовании ее добились.


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

Есть некий проект название не могу озвучивать. Cо схемой работы 2 видов: 1. сервер приложений jboss вынесен на отдельную железку от сервера db
2 все работает на 1м железе. Дополнительно в эту железку 1С выгружает данные. Начальные тесты показали что при расположении на 1м физическом сервере получаем, более быстрый вывод, реальных запросов и выгрузок в эту бд. На разделенном получаем условно от 30 до 50% потерь по времени на выгрузке, да и запросы друг на друга идут дольше. Процентное соотношение сохраняется даже при замене железок. Заказчики хотели бы довести потери на разделении сервера приложений от сервера бд до 20%, хотя судя по всему задача не решаема. Вот зачем это все потребовалось. Спасибо за любые коментарии.
13 ноя 20, 16:09    [22231509]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Опишу поподробней
Схема1- сервер приложений jboss + postgres работают на 1м железе
Схема2- сервер postgres вынесен на отдельную железку
В jboss 1С выгружает данные.
Тесты в том числе и pgbench в 10 потоков, показали что при расположении на 1м физическом сервере получаем, более быстрый вывод, реальных запросов и выгрузок в эту бд.
На разделенном получаем условно от 30 до 50% потерь по времени. Заказчик говорит уменьшайте задержку в сети, настройками. Сами же пришли к выводу что все что можно сделано. Поэтому и хотелось бы услышать мнение со стороны.
13 ноя 20, 16:28    [22231533]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
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: кстати у меня на одном из кластеров по лучше вот что имеем:
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
13 ноя 20, 17:07    [22231571]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
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 тыс.
13 ноя 20, 21:05    [22231725]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Dementyev
Member

Откуда:
Сообщений: 3
[quot Leonid Kudryavtsev#22231725]
batong

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

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

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

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

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

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

Насчет аренды кота - это тоже вопрос открытый и вполне рассматриваемый, все зависит от прайса и того, что сможете предложить.

Сообщение было отредактировано: 13 ноя 20, 23:23
13 ноя 20, 23:26    [22231796]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Dementyev
Member

Откуда:
Сообщений: 3
Параллельно решению вопросов выгрузки решаем еще другие вопросы.
Мы уже научись repmgr, сейчас учимся barman.
13 ноя 20, 23:55    [22231802]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
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 ) мурзилка
14 ноя 20, 00:14    [22231806]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
Ссылка на старое обсуждение в разделе Hardware. Есть ссылки на продукты/карты/решения (для того времени).

https://www.sql.ru/forum/1129883-1/mozhno-li-zaderzhku-v-seti-1-gigabit-priblizit-k-teoreticheskoy
14 ноя 20, 00:56    [22231822]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
batong,

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

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

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

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

Есть технологии сетевых карт (LSO и другие) которые ускоряют некоторые шаги, но сами шаги остаются.
Послать конверт соседу почтой занимает дольше, чем отнести его из одной комнаты в другую.
14 ноя 20, 05:43    [22231892]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
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
14 ноя 20, 09:25    [22231917]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Dementyev
Member

Откуда:
Сообщений: 3
Maxim Boguk

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

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

Прошу тапками не кидать за следующий вопрос, мы только учимся.
Если выключить ssl у postgres, это не повлияет на barman?
Пытаемся (обучаемся) использовать стратегию с rsync, ключи SSH же openssl

Сообщение было отредактировано: 14 ноя 20, 14:39
14 ноя 20, 14:40    [22232050]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
Dementyev,

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

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

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

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

Сообщение было отредактировано: 14 ноя 20, 17:35
14 ноя 20, 17:22    [22232098]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Maxim Boguk,
Как понимаю ssl отключаем в параметрах postgres, ssl = off параметр был закомментирован, но по умолчанию и должно срабатывать ssl = off , так же в сборке отключен selinux.


После добавления в запрос explain analyze
Получаем увеличение времени . Это localhost
-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


Это с удаленного сервера
-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
>   -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


Удаленный запрос
-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? По мониторингу нагрузки упирания в производительность оборудования нет на обоих сборках.
16 ноя 20, 11:30    [22232706]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1181
batong,

а проверьте в каком режиме у вас процессоры ( /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ). Если не performance - то для такой мелкой задачи CPU может даже решить не выходить из powersave и продолжить работать, соответственно, на интересной частоте существенно ниже номинальной.
16 ноя 20, 12:23    [22232772]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
IMHO
batong

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

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

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

Связка db-app для второго теста: db 2х процессорный но по частотам слабее гораздо...

Время: 0,400 мс
Time: 0.948 ms


NUMA ?
16 ноя 20, 12:54    [22232806]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Melkij
batong,

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

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

перевел ядра на cpu в режим performance
на серверах db и app по этой статье [url=]https://community.mellanox.com/s/article/how-to-set-cpu-scaling-governor-to-max-performance--scaling-governor-x[/url]
получил результаты очень обнадеживающие:
localhost
-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



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

-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 в данном режиме чем обернется в будущем?

Сообщение было отредактировано: 16 ноя 20, 14:30
16 ноя 20, 14:33    [22232941]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Leonid Kudryavtsev
IMHO
NUMA ?

Да возможно вы тоже правы. В загрузчике она не выключена. Сравню уже в отдельном замере, вернув режим работ процессоров powersave. Огромное спасибо.

Сообщение было отредактировано: 16 ноя 20, 14:51
16 ноя 20, 14:56    [22232976]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
шаманством занимаетесь

IMHO Перед тем как решать, сначала нужно сформулировать задачу / проблему. Внятные и осмысленные требования по производительность в договоре/доп.соглашениях/прочих документах.

"На разделенном получаем условно от 30 до 50% потерь по времени. Заказчик говорит уменьшайте задержку в сети, настройками."
" Заказчики хотели бы довести потери на разделении сервера приложений от сервера бд до 20%, хотя судя по всему задача не решаема."

эти требования не внятные и не осмысленные

1) Сферические проценты потерь

Довести потери до 1 % очень легко! Просто нужно взять старенький комп 486 SX 25, попытаться собрать под него постгресс...

Запрос будет выполняться 1 минуту, запрос по сети 1 минуту и пол секунды - требуемые параметры достигнуты !!!

note: вместо 486 SX, можно придумать и другие, более современные технологии "ускорения через замедление )))"- своп, разместить важные части базы на флоппи дисках/USB-флешках и так далее и так далее...

2) Как считать потери и задержку в сети?

Можно считать latency сети netperf / qperf. Тут все просто! В два раза должно меняться просто включением/выключением interrupt moderation
Если уже выключено ))), то перед показом заказчика включаем и потом выключаем... шарик входит и выходит ( C ) Ио

Если на реальном приложении, то и netperf и psql не показатель. И может очень слабо (и вплодь до обратного, по тесту улучшаем, на деле ухудшаем) коррелировать с работой реального приложения. AFAIK
16 ноя 20, 16:10    [22233053]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1181
batong
ПС. остается вопрос постоянная работа cpu в данном режиме чем обернется в будущем?

Чуть выше энергопотребление в простое. Возможно чуть более агрессивный turbo boost под нагрузкой. В общем - режим работы штатный для CPU.
ЕМНИП, железо в performance стартует всегда, в powersave его потом ОС переключает.
16 ноя 20, 18:34    [22233218]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
batong
Member

Откуда:
Сообщений: 9
Спасибо всем за помощь, на мелких запросах получилась разница около 6%. Совокупная разница при пакетных выгрузках около 16%.
Дальше только если использовать оптимизацию сети адаптерами из постов выше, ну и сокращать мелкие запросы. Может кому то тоже будет полезной статья https://www.ibm.com/developerworks/ru/library/l-cpufreq-2/index.html

Сообщение было отредактировано: 18 ноя 20, 11:11
18 ноя 20, 11:14    [22234428]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение скорости выполнения запроса на localhost и с соседнего сервера  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9249
batong,

Спасибо за информацию и за ссылку на статью, достаточно полезная.
18 ноя 20, 15:15    [22234656]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / PostgreSQL Ответить