У меня наоборот, практически постоянно открыта вакансия, и проблема найти человека. Да, платим не как в faang, но и требования приземленные. В итоге или нулевые студенты или "меньше 300к в месяц??? Да-нуууу".
Тоже процесс system выжирает cpu. Причем после того как пытается понизить частоту до 0.8 ггц, типа сэкономить, загрузка цп поднимается до 100% и висит так часами, ревя вентилятором. Частота подростает при любой пользовательской активности и загрузка цп падает в 0. Так и не смог победить, видать особенность асуса... Вирусов тоже не нашлось. Может подскажете что?
Nuc8i3 используется как рабочее место. 2 года назад за 15 000 руб покупался. Теперь таких цен нет. А машинка замечательнейшая, всё что нужно умеет и делает. Практически не шумит, производительности хватает и студии и идее. И места за монитором не занимает вовсе. Сплошные плюсы.
Я такие коды точно изучал в университете. И самосинхрон и самоисправление и достаточность. Жаль не пригодилось только, и забылось. Но математическое обоснование модемной скорости 33.6 помню всех поразило. Когда сплошная математика, причем чисто умозрительная, бумажная, а тут вдруг раз и пример из реальной жизни....
А будут ли доступны по самолету дополнительные данные, описания, или лучше исходники по расчету ВПХ? Да вопрос-то скорее не к автору статьи, а к производителю.
Павел, оказалось немного интереснее чем выглядело на первый взгляд. Посмотрите лог ниже , это два вызова одного и того же запроса подряд:
2022-11-07 12:27:28.158 MSK [3344] [192.168.200.58] СООБЩЕНИЕ: duration: 0.024 ms plan:
Query Text: SELECT exists(select 1 from model
where p_key = elements.pKey and
model_id = elements.id and
type_code = elements.vtc and
code = elements.vc and
unique_id != uniqueId)
Result (cost=8.18..8.19 rows=1 width=1) (actual time=0.023..0.023 rows=1 loops=1)
Output: $0
Buffers: shared hit=3 dirtied=1
InitPlan 1 (returns $0)
-> Index Scan using model_su052_p_key_model_id_idx on ffp.model_su052 (cost=0.15..8.18 rows=1 width=0) (actual time=0.022..0.022 rows=0 loops=1)
Index Cond: ((model_su052.p_key = 'SU052 '::character(6)) AND ((model_su052.model_id)::text = '4'::text))
Filter: (((model_su052.unique_id)::text <> '4'::text) AND ((model_su052.type_code)::text = 'AX'::text) AND ((model_su052.code)::text = 'SU'::text))
Buffers: shared hit=3 dirtied=1
2022-11-07 12:27:29.831 MSK [3344] [192.168.200.58] СООБЩЕНИЕ: duration: 0.035 ms plan:
Query Text: SELECT exists(select 1 from model
where p_key = elements.pKey and
model_id = elements.id and
type_code = elements.vtc and
code = elements.vc and
unique_id != uniqueId)
Result (cost=8.34..8.35 rows=1 width=1) (actual time=0.030..0.030 rows=1 loops=1)
Output: $0
Buffers: shared hit=3 dirtied=1
InitPlan 1 (returns $0)
-> Append (cost=0.15..8258.58 rows=1009 width=0) (actual time=0.029..0.029 rows=0 loops=1)
Buffers: shared hit=3 dirtied=1
Subplans Removed: 1008
-> Index Scan using model_su053_p_key_model_id_idx on ffp.model_su053 (cost=0.15..8.18 rows=1 width=0) (actual time=0.029..0.029 rows=0 loops=1)
Index Cond: ((model_su053.p_key = $14) AND ((model_su053.model_id)::text = ($15)::text))
Filter: (((model_su053.unique_id)::text <> ($2)::text) AND ((model_su053.type_code)::text = ($16)::text) AND ((model_su053.code)::text = ($17)::text))
Buffers: shared hit=3 dirtied=1
со временем, на 15..50 вызов в одном подключении, бд решает что нужно сделать generic план и мучается с ним, получая до 5000 локов на транзакцию. Лечится путем установки
plan_cache_mode = force_custom_plan
Что, кстати, вызывает пятикратное ускорение операций в бд.
Но тут, как мне кажется, на лицо недоработка оптимизатора. Он сначала блокирует все партиции, а потом уже делает partition pruning. А по хорошему сначала б делать блокировку основной таблицы, потом отфильтровать неподходящие партиции и доблокировать оставшиеся.
Спасибо огромное, пусть ваш пример и прост сам по себе. В проде под нагрузкой пришлось увеличивать max locks до тысяч, иначе валилось. И сейчас я вижу что под конец записи , которая осуществляется хранимой процедурой, у меня 13 локов. Я в клиенте могу и вычисляю партицию до обращения к бд.
Значит как исследовать и что - теперь вроде понятно. Тут как вариант еще спринг шалит. Я чаще раза в сутки тут писать не могу, но по результатам отпищусь или уточняющие вопросы задам.
@pluzanov, Павел, а нет ли каких изменений в системе блокировок при работе с секционированными таблицами? Как я понимаю, при планировании запроса идет блокировка всех партиций, в том числе и не задействуемых фактически, и получаем
ERROR: out of shared memory Hint: You might need to increase max_locks_per_transaction.
Я так и не смог вечером подать заявление. Форма неверная. Хотя полностью соответствует тем формам, что коллеги днем подавали успешно. Подпись проверяется успешно. Хз в чем проблема.
Странно, ттт. И паспорт российский и номер телефона были приняты летом.
А какой сегодня процент прямых продаж и продаж через gds?
Было очень интересно, сложно, нужно перечитать еще пару раз.
У Вебба орбита не близкая, легко не обслужить.
Нет конечно, какая, прости Господи, Канада. Но меня не покидает мысль что как и автор мы делаем что то не то, или мир сломан.
У меня наоборот, практически постоянно открыта вакансия, и проблема найти человека. Да, платим не как в faang, но и требования приземленные. В итоге или нулевые студенты или "меньше 300к в месяц??? Да-нуууу".
Перевод задержался на год.
Отправка логов в loki описана, а как трейсы добираются до tempo? И как tempo связан с loki? Про эту настройку ни в оригинале, ни у вас нет ничего.
Тоже процесс system выжирает cpu. Причем после того как пытается понизить частоту до 0.8 ггц, типа сэкономить, загрузка цп поднимается до 100% и висит так часами, ревя вентилятором. Частота подростает при любой пользовательской активности и загрузка цп падает в 0. Так и не смог победить, видать особенность асуса... Вирусов тоже не нашлось. Может подскажете что?
Да, с olap тишина, как будто железо в наши дни и средствами oltp может порешать задачи аналитики. Но нет же!
Nuc8i3 используется как рабочее место. 2 года назад за 15 000 руб покупался. Теперь таких цен нет. А машинка замечательнейшая, всё что нужно умеет и делает. Практически не шумит, производительности хватает и студии и идее. И места за монитором не занимает вовсе. Сплошные плюсы.
Я такие коды точно изучал в университете. И самосинхрон и самоисправление и достаточность. Жаль не пригодилось только, и забылось. Но математическое обоснование модемной скорости 33.6 помню всех поразило. Когда сплошная математика, причем чисто умозрительная, бумажная, а тут вдруг раз и пример из реальной жизни....
Прям ZORG какой-то.
А что на счет application (advisory) lock в бд?
И на сколько часто случается, что по одному клиенту приходит столько сообщений, что происходит гонка?
А будут ли доступны по самолету дополнительные данные, описания, или лучше исходники по расчету ВПХ? Да вопрос-то скорее не к автору статьи, а к производителю.
А я проникся теорией Темного леса. Отличная идея, не к чему придраться.
Павел, оказалось немного интереснее чем выглядело на первый взгляд. Посмотрите лог ниже , это два вызова одного и того же запроса подряд:
со временем, на 15..50 вызов в одном подключении, бд решает что нужно сделать generic план и мучается с ним, получая до 5000 локов на транзакцию. Лечится путем установки
plan_cache_mode = force_custom_plan
Что, кстати, вызывает пятикратное ускорение операций в бд.
Но тут, как мне кажется, на лицо недоработка оптимизатора. Он сначала блокирует все партиции, а потом уже делает partition pruning. А по хорошему сначала б делать блокировку основной таблицы, потом отфильтровать неподходящие партиции и доблокировать оставшиеся.
Спасибо огромное, пусть ваш пример и прост сам по себе. В проде под нагрузкой пришлось увеличивать max locks до тысяч, иначе валилось. И сейчас я вижу что под конец записи , которая осуществляется хранимой процедурой, у меня 13 локов. Я в клиенте могу и вычисляю партицию до обращения к бд.
Значит как исследовать и что - теперь вроде понятно. Тут как вариант еще спринг шалит. Я чаще раза в сутки тут писать не могу, но по результатам отпищусь или уточняющие вопросы задам.
@pluzanov, Павел, а нет ли каких изменений в системе блокировок при работе с секционированными таблицами? Как я понимаю, при планировании запроса идет блокировка всех партиций, в том числе и не задействуемых фактически, и получаем
ERROR: out of shared memory
Hint: You might need to increase max_locks_per_transaction.
Я так и не смог вечером подать заявление. Форма неверная. Хотя полностью соответствует тем формам, что коллеги днем подавали успешно. Подпись проверяется успешно. Хз в чем проблема.
Вот когда в 11 классе писал реферат про гравитацию, то не смог найти ни одного человека, способного объяснить эту тензорную алгебру.
Есть еще вполне годный Fork. Пробуйте, автор отзывчив.