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