Подскажите пожалуйста, 60мс для мелкого запроса с обновлением 1 поля

много?

нет

Спасибо

Если есть нужные индексы и тд, то скорей всего напрямую зависит от диска. Для ssd 60мс много, для hdd норм

Там как бы ссд, но сетевой, поэтому решил спросить

а сколько round trip до диска и обратно?

А чем это проверить?

пингом например) или каким-то около-бесплатным селектом. ну и в целом при таких вопросах полезно инфу из запиненного сообщения приложить

я просто не совсем понимаю как можно диск пингануть

Есть утилита fio. Можно dd попробовать. C postgres идёт обычно pg_test_fsync

ну диск же на каком-то сервере/СХД существует, вот это и пингануть. Либо да, хорошие советы про dd

Сетевой в каком плане?

gercovv

Это жопа да простят меня за такую лексику

gercovv

Короче у вас все могло быть куда хуже

Могло?

Тоесть все не так плохо?

ну, не понятно, что такое "сетевой диск". Самба? :) NFS? SAN? там радикально разные скорости доступа у разных вариантов.

gercovv

А, цэф? Тогда вообще нормально, быстро дажэ.

Сеф это распределённая ФС, она не предполагает быстрого доступа к данным

Насколько плохо будет если на такой диск поставить бд?

Просто не надо так делать и все

ну по скорости там вроде не все так плохо

Да вроде не так и плохо (ну, на самом деле никто в серьёз не тэстировал), только очень-очень медленно.

Всё. Там дажэ обещаний нормальных иопсов нет. Да и раундтрипов тожэ.

И как быть получается

Архитектору сообщить — пусть он думает.

Ну это прям больно будет? Или просто не очень приятно?)

Очень и очень

Проблема только в скорости?

Не только, но это уже вне компетенций dba

Кому как. Вообще — говорю жэ, ничего такого, только в несколько десятков раз упадёт скорость.

В несколько десятков? Если раньше операция занимала 20-30 мс, сейчас 50-70

Вы даже не пытаясь промоделироапть реальную нагрузку

Ну, цэфовые массивы как таковые имеют привычку разваливаться, конечно. С меньшэй вероятностью, чем один сервер супермикры — но всё рпвно с заметной. Так что это тожэ можэт дойти. Но это к базе как таковой не относится.

Я не про "операцию", а про скорость работы СУБД типичного профиля с диском. Вашы операцыи могут занимать при этом сколько угодно и хоть вообще ничего не заметить (по очевидным причинам).

Стоит запустить Pgbench для проверки?

Нет. Но если очень хочется — то, конечно, можно.

» Вашы операцыи могут занимать при этом сколько угодно и хоть вообще ничего не заметить (по очевидным причинам). Ну да, именно по этому нагрузочный тест надо делать не на абстрактном пгбенче, а на самой прикладухе. Может она во время бизнес-операции ещё 5 секунд по сети ко внешней системе ходит, а мы тут за 60мс переживаем.

Лучше будет проверить как вы писали выше, просто большим кол-вом запросов?

большим количеством тривиальных запросов можно померять раундтрип до базы. Если например он у вас 40мс, то значит ваш апдейт занимает на самом деле только 20. Но при этом надо действительно либо знать заранее, либо путём нагрузочного теста на прикладухе выяснить: насколько вообще важна длительность этого запроса.

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

Вообще, когда я говорил про 60мс я не совсем верно сказал, это время выполнения функции, в которой идет 7 подряд идущих запросов

ну тем более :) Может вы 59мс на какой-нибудь блокировке висите.

Тогда нет смысла беспокоиться о том что диск сетевой?

прогоните более-менее реалистичный нагрузочный тест и посмотрите, устраивает ли вас производительность. Если да, то всё остальное ерунда :)

В виде реального нагрузочного теста подойдет вызов данной функции 1к раз?

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