ОЛТП, система. Но с другой стороны в ОЛТП системах видел запросы Dynamic SQL по 4 GB текст запроса) Понятно что транзакционная модель с сериализацией обязывает "держать в уме" какое то количество памяти. Транзакции смотрел, закрываются. но в моменте может быть N открытых транзакций. Но идея в другом, хочется некоторых универсальных подходов. Про разделяемую память в постгри это отдельная история, специально не стал начинать с этого обсуждение иначе холивар был бы обеспечен.
А что это такое?) хотя я уже вроде описывал ситуацию. Дайте утилиту, которая по сигнатуре запроса будет собирать запрос, и самое главное все связанные структуры заполненные ранее, типа временных таблиц. и потом будет воспроизводить. Этого нет, буду рад ошибаться
повторюсь, если на основании какой то системы мониторинга подобные вопросы можно оценивать, все мои рассуждения сводятся к нулю. Но я готов потерпеть поражение ради знаний!) ЦПУ, там более менее понятно, а с памятью много вопросов. Буду готов признать свою неправоту.
Есть в математике простые вопросы типа большой теоремы ферма. Простые в формулировке, но ответить на них сложно.. Я предлагаю один из тестов по которому можно оценить практически систему мониторинга, ее оценку. Один из универсальных тестов. Не сердитесь, я в этой теме тоже разбираюсь, мое мнение отличается от мнения компании. Мне интересен вопрос с научной точки зрения. Поднимаю дискуссию, никому не хочу ничего доказывать.
Ну в моем случае я уже расписывал, что неразумно делать тестовый стенд аналогичный рабочему серверу. Можно значительно уменьшить размер памяти, провести тесты и потом сделать аппроксимацию. Я надеюсь на это. Многие эксперименты я проводил на MSSQL, сознательно ограничивая память до минимума, гротеска , там было попроще. Здесь за счет виртуализации можно управлять.
Система меняется, нагрузочные тесты не успевают. Многопоточная, высоконагруженная система. Что в этих условиях мерять? Я предлагаю некоторые подходы которые помогают ввести какие то метрики, ничего больше. Мы с реальной системы собираем все(потенциально опасные) запросы. Воспроизводим автоматизированно на тестовой среде, без влияния других факторов. И получаем приоритезацию по их потенциальному влиянию на работу системы. Если на основании данных мониторинга это можно рассчитывать, то мои все рассуждения имеют сугубо теоретический характер.(но докажите мне, на простых примерах)
Если вы можете на основании средств мониторинга решить эту практическую задачу(ок, пускай гипотетическую), простой универсальный эксперимент. Скажите как, я готов заплатить, ради истины даже если вы потерпите неудачу.
Эксперимент должен воспроизводится, это раз! Зная данные этих экспериментов выполненных системой на тестовой среде я могу сделать очень далеко идущие выводы. Доказать они могут - буквально выполненные одновременно(миниально) Х запросов (типа -Z) приводят к свопированию. Можно ли на основании этого делать вывод о потреблении памяти - ну это слишком просто(разделить и все, ну я писал), но выводы практические вполне.
поэтому и предлагаю один из "дешевых" универсальных подходов. Смотря потом на средства мониторинга и зная что этот запрос приводил к свопирования в Х раз(одновременных запусков), а этот Х/100 - я буду четко понимать приоритеты оптимизации. Кому хватит времени и усердия проводить качественно такие эксперименты?
Нагрузочные тесты дорогие и у нас их не ценят.(мое субьективное мнение) А еще они не отображают часто динамически изменяемую нагрузку в процессе эволюции ит системы. Часто в продакшн выпускается какие то критичные обновления мимо системы нагрузочного тестирования.
Со всеми пунктами согласен. Но верю что есть способы увеличить вероятность оценок. Вот и предлагаю универсальные новые подходы, пускай меня и критикуют. Что то срабатывает, что то нет. Напоминаю , эта статья родилась после серии нагрузочных тестов.
Пробовал , так не работает. Там даже вопросы связанные с временным выделением памяти в очень тяжелых запросах стоят особняком. Например когда она освобождается? Вопросы с разделяемой памятью, как ее считать? Но и заметьте вы предлагаете похоже ,что и я. Проведите аккуратно эксперимент - 1х, это важно(без воздействия среды, иначе как с повторяемостью экспериментов и результатов). Но я боюсь даже в этом случае замеры и дальнейшая аппроксимация могут привести к неправильным выводам. Я же предлагаю автоматизированный практический тест.
Коллеги, не обессудьте. Мне хотелось бы поднять дебаты. Я рад что идет обсуждение. ЦПУ более менее понятно как считать. Не понятно как посчитать память используемую запросом? Философски даже, в каких попугаях мерять? Я предложил методику, критикуйте , предлагайте свои подходы. Но в целом вопрос стоит- как на высоконагруженных системах научится предугадывать когда настанут критические ситуации? С памятью мне не понятно, я ж писал, готов предложить написать статью и профинансировать , кто готов вложить свое время в полноценные исследования.
Повторюсь.... Хочется универсализма. Я предложил один из подходов. Предположим есть у вас данные мониторинга. Есть запрос потребляющий память. Есть сервер с памятью Х, Сможете ли вы рассчитать на основании данных мониторинга плюс минус сколько таких запросов можно выполнить одновременно пока не начнется свопирование? Если сможете, просьба конкретные параметры и алгоритмы в студию.
Мне кажется вы статью вообще не читали. Хочется универсализма. Я предложил один из подходов. Предположим есть у вас данные мониторинга. Есть запрос потребляющий память. Есть сервер с памятью Х, Сможете ли вы расчитать на основании данных мониторинга плюс минус сколько таких запросов можно выполнить одновременно пока не начнется свопирование? Если сможете, просьба конкретные параметры и алгоритмы в студию.
Так там она и искалась в том числе. Не получается по этой информации спрогнозировать поведение системы. Есть идеи следующую статью оформить в виде скриптов которые будут заполнять таблицы, формировать запросы и затем разобрать детальней все параметры. Но самостоятельно я это делал и не раз.
Не стал я базовые вещи расписывать , дабы статью не уводить дальше от темы. Вы мне накидали ссылок, зачем? Все это не по теме. Давайте я вам приведу пример а потом задам вопрос и просьба ответьте на него конкретно а не про сферического коня в вакуме. https://postgrespro.ru/docs/postgresql/17/pgstatstatements и тому подобное могу получить интересующий нас запрос но воспроизвести в большинстве случаев его не получится. Приведу пример, 1С формирует запросы с использование временных таблиц. То есть заполняется временная таблица как правило на 1000-и записей и потом она или они используются в запросе. С помощью прокси я могу сохранить сам запрос и состояние временных таблиц и потом воспроизвести на тестовом сервере. Вопрос к вам конкретный ,приведите мне утилиту которая могла бы сохранить и затем воспроизвести полностью интересуемый запрос? Я таких не знаю, поэтому и предлагаю решение. И просьба сначала на этот вопрос ответить а потом я готов подискутировать как я не умею определять тяжелые запросы и все остальное)
Ну обращайтесь если что, так то конечно у меня например гораздо больший опыт в МSSQL, хотя там тоже много "черных ящиков", а исходников нет. Но я уже написал в другом посте свое мнение по поводу исходников, это не всегда имеет определяющее значение.
Это большое заблуждение что в открытом ПО, не может быть закладок, что оно лучше описано чем коммерческое и т.п. Найдите мне спеца по С, который мог бы читать чужой код описывать его, знает СУБД и алгоритмы оптимизации. Кто умеет хотя бы проводить эксперименты правильные. В большинстве случаев эффективней не читать код а начинать с экспериментов и потом уже включать механизмы отладки и т.п.
ОЛТП, система. Но с другой стороны в ОЛТП системах видел запросы Dynamic SQL по 4 GB текст запроса) Понятно что транзакционная модель с сериализацией обязывает "держать в уме" какое то количество памяти. Транзакции смотрел, закрываются. но в моменте может быть N открытых транзакций. Но идея в другом, хочется некоторых универсальных подходов. Про разделяемую память в постгри это отдельная история, специально не стал начинать с этого обсуждение иначе холивар был бы обеспечен.
Золотые слова;)!
А что это такое?) хотя я уже вроде описывал ситуацию. Дайте утилиту, которая по сигнатуре запроса будет собирать запрос, и самое главное все связанные структуры заполненные ранее, типа временных таблиц. и потом будет воспроизводить. Этого нет, буду рад ошибаться
повторюсь, если на основании какой то системы мониторинга подобные вопросы можно оценивать, все мои рассуждения сводятся к нулю. Но я готов потерпеть поражение ради знаний!) ЦПУ, там более менее понятно, а с памятью много вопросов. Буду готов признать свою неправоту.
Есть в математике простые вопросы типа большой теоремы ферма. Простые в формулировке, но ответить на них сложно.. Я предлагаю один из тестов по которому можно оценить практически систему мониторинга, ее оценку. Один из универсальных тестов. Не сердитесь, я в этой теме тоже разбираюсь, мое мнение отличается от мнения компании. Мне интересен вопрос с научной точки зрения. Поднимаю дискуссию, никому не хочу ничего доказывать.
Ну в моем случае я уже расписывал, что неразумно делать тестовый стенд аналогичный рабочему серверу. Можно значительно уменьшить размер памяти, провести тесты и потом сделать аппроксимацию. Я надеюсь на это. Многие эксперименты я проводил на MSSQL, сознательно ограничивая память до минимума, гротеска , там было попроще. Здесь за счет виртуализации можно управлять.
Система меняется, нагрузочные тесты не успевают. Многопоточная, высоконагруженная система. Что в этих условиях мерять? Я предлагаю некоторые подходы которые помогают ввести какие то метрики, ничего больше. Мы с реальной системы собираем все(потенциально опасные) запросы. Воспроизводим автоматизированно на тестовой среде, без влияния других факторов. И получаем приоритезацию по их потенциальному влиянию на работу системы. Если на основании данных мониторинга это можно рассчитывать, то мои все рассуждения имеют сугубо теоретический характер.(но докажите мне, на простых примерах)
Если вы можете на основании средств мониторинга решить эту практическую задачу(ок, пускай гипотетическую), простой универсальный эксперимент. Скажите как, я готов заплатить, ради истины даже если вы потерпите неудачу.
Эксперимент должен воспроизводится, это раз! Зная данные этих экспериментов выполненных системой на тестовой среде я могу сделать очень далеко идущие выводы. Доказать они могут - буквально выполненные одновременно(миниально) Х запросов (типа -Z) приводят к свопированию. Можно ли на основании этого делать вывод о потреблении памяти - ну это слишком просто(разделить и все, ну я писал), но выводы практические вполне.
Хочется иногда железобетонных гарантий)
поэтому и предлагаю один из "дешевых" универсальных подходов. Смотря потом на средства мониторинга и зная что этот запрос приводил к свопирования в Х раз(одновременных запусков), а этот Х/100 - я буду четко понимать приоритеты оптимизации. Кому хватит времени и усердия проводить качественно такие эксперименты?
Нагрузочные тесты дорогие и у нас их не ценят.(мое субьективное мнение) А еще они не отображают часто динамически изменяемую нагрузку в процессе эволюции ит системы. Часто в продакшн выпускается какие то критичные обновления мимо системы нагрузочного тестирования.
Со всеми пунктами согласен. Но верю что есть способы увеличить вероятность оценок. Вот и предлагаю универсальные новые подходы, пускай меня и критикуют. Что то срабатывает, что то нет. Напоминаю , эта статья родилась после серии нагрузочных тестов.
Пробовал , так не работает. Там даже вопросы связанные с временным выделением памяти в очень тяжелых запросах стоят особняком. Например когда она освобождается? Вопросы с разделяемой памятью, как ее считать? Но и заметьте вы предлагаете похоже ,что и я. Проведите аккуратно эксперимент - 1х, это важно(без воздействия среды, иначе как с повторяемостью экспериментов и результатов). Но я боюсь даже в этом случае замеры и дальнейшая аппроксимация могут привести к неправильным выводам. Я же предлагаю автоматизированный практический тест.
Коллеги, не обессудьте. Мне хотелось бы поднять дебаты. Я рад что идет обсуждение. ЦПУ более менее понятно как считать. Не понятно как посчитать память используемую запросом? Философски даже, в каких попугаях мерять? Я предложил методику, критикуйте , предлагайте свои подходы. Но в целом вопрос стоит- как на высоконагруженных системах научится предугадывать когда настанут критические ситуации? С памятью мне не понятно, я ж писал, готов предложить написать статью и профинансировать , кто готов вложить свое время в полноценные исследования.
Повторюсь.... Хочется универсализма. Я предложил один из подходов. Предположим есть у вас данные мониторинга. Есть запрос потребляющий память. Есть сервер с памятью Х, Сможете ли вы рассчитать на основании данных мониторинга плюс минус сколько таких запросов можно выполнить одновременно пока не начнется свопирование? Если сможете, просьба конкретные параметры и алгоритмы в студию.
Мне кажется вы статью вообще не читали. Хочется универсализма. Я предложил один из подходов. Предположим есть у вас данные мониторинга. Есть запрос потребляющий память. Есть сервер с памятью Х, Сможете ли вы расчитать на основании данных мониторинга плюс минус сколько таких запросов можно выполнить одновременно пока не начнется свопирование? Если сможете, просьба конкретные параметры и алгоритмы в студию.
Так там она и искалась в том числе. Не получается по этой информации спрогнозировать поведение системы. Есть идеи следующую статью оформить в виде скриптов которые будут заполнять таблицы, формировать запросы и затем разобрать детальней все параметры. Но самостоятельно я это делал и не раз.
Не стал я базовые вещи расписывать , дабы статью не уводить дальше от темы. Вы мне накидали ссылок, зачем? Все это не по теме. Давайте я вам приведу пример а потом задам вопрос и просьба ответьте на него конкретно а не про сферического коня в вакуме. https://postgrespro.ru/docs/postgresql/17/pgstatstatements и тому подобное могу получить интересующий нас запрос но воспроизвести в большинстве случаев его не получится. Приведу пример, 1С формирует запросы с использование временных таблиц. То есть заполняется временная таблица как правило на 1000-и записей и потом она или они используются в запросе. С помощью прокси я могу сохранить сам запрос и состояние временных таблиц и потом воспроизвести на тестовом сервере. Вопрос к вам конкретный ,приведите мне утилиту которая могла бы сохранить и затем воспроизвести полностью интересуемый запрос? Я таких не знаю, поэтому и предлагаю решение. И просьба сначала на этот вопрос ответить а потом я готов подискутировать как я не умею определять тяжелые запросы и все остальное)
Ну обращайтесь если что, так то конечно у меня например гораздо больший опыт в МSSQL, хотя там тоже много "черных ящиков", а исходников нет. Но я уже написал в другом посте свое мнение по поводу исходников, это не всегда имеет определяющее значение.
Это большое заблуждение что в открытом ПО, не может быть закладок, что оно лучше описано чем коммерческое и т.п. Найдите мне спеца по С, который мог бы читать чужой код описывать его, знает СУБД и алгоритмы оптимизации. Кто умеет хотя бы проводить эксперименты правильные. В большинстве случаев эффективней не читать код а начинать с экспериментов и потом уже включать механизмы отладки и т.п.