Здравствуйте, Maxim S. Shatskih, Вы писали:
GZ>>Это как раз не идеал. Если при нагрузочном тестировании я получил этот график, то это тревожный звонок о том, что система не может качественно адаптировать ресурсы под свои нужды. 
MSS>Нет.
MSS>"Тревожный звонок" — это когда при росте числа посылаемых запросов линейно с ним растет время исполнения каждого запроса, _а показатели нагрузки машины типа процессора или диска такие же, причем низкие, и даже чуть падают_.
MSS>У нас такое было на моей бывшей работе в конце 90х. Причина, как оказалось — дурацкий паттерн запросов к базе, из-за чего практически любой запрос вставал на одном и том же локе на одной и той же таблице внутри датабазного движка, и держалась эта таблица залоканной до конца транзакции бизнес-логики.
Это тоже. Но я говорил о зависимости нагрузки и времени ответа без всякой расшифровки. Если мы знаем что общих ресурсов нет, то программа полностью параллельна, и соответсвенно scalability как таковое нас не интересует. Load Tests интересуют именно когда нагрузка предельна высока. Приведу другой пример: 20 одновременных вызовов занимает время t, 30 одновременных вызовов занимает время t. Такое вполне возможно, но мы знаем что процессор 1, и следовательно мы сидим на некотором устройстве которое ограничивает производительность. И это устройство — и есть "тревожный звонок". И тут уже нужно просматривать можем ли мы обеспечить вертикальную или горизонтальную масштабируемость учитывая данный ресурс, или может выделить некоторые расчеты на процессор, или увеличить нагрузку на кэш.
В случае линейности графика, у меня больше уверенности в адекватности системы.
MSS>Это практически полное отсутствие скалабилити.
Отчего-же. В случае горизонтальной расширяемости (добавим компьютер в кластер) — полное отсутсвие уже под знаком вопроса. Хотя согласен, что подобные решения не слишком хороши, точнее очень нехорошие.
MSS>Вот именно ситуация, когда ожидание на локах и в очередях вносит главный вклад во время выполнения запроса, и есть отсутствие масштабируемости.
+1
MSS>Понятно, что время ожидания на локе в этой системе будет порядка N — 1, где N — число одновременных запросов. Мы получаем как раз вот эту плохую картину — линейный рост времени выполнения с ростом числа одновременных запросов, при том, что нагрузка на машину мала — ибо реально выполняется в каждый момент времени только 1 запрос.
MSS>Так что такая картина — это очень плохо.
Я бы сказал так. Вредны не сами локи, вредно время которое код находится в непараллельном режиме.
GZ>>Такое может быть либо при очень низкой загрузке(тот вопрос когда масштабируемость как проблемы вообще нет), либо при ресурсе который дает только постоянную производительность (и к нему нужно очень осторожно отнестись).
MSS>Нет.
MSS>Еще раз — "почти независимость" времени выполнения запроса от количества запросов (до какого-то потолка, на котором это кончается, а начинается трешинг с обвальным ростом времени выполнения), при линейном росте показателей нагрузки машины от количества запросов — вот это правильная скалабильность.
MSS>Это означает, что время ожидания на локах почти не вносит вклада во время исполнения, т.е. этот вклад вносится только неизбежными вещами типа "надо исполнить вот этот код", "надо исполнить вот этот запрос" и "надо прочитать с диска вот столько". Т.е. скалабильность хороша, ее оптимизировать не надо (хотя, возможно, надо оптимизировать производительность).
MSS>Оптимизация уже производительности а) снизит время выполнения "на пустой машине" б) отодвинет вдаль порог, где начинается обвал скалабильности.
+1. Именно это и требовалось доказать. Перенос нагрузки с одного нагруженного ресурса на другое отодвинет порог. Только вообще-то я против термина "на пустой машине". Производительность на пустой машине меня мало волнует.(это другое измерение) Волнует только какое количества времени код выполняется параллельно, и кол-во времени которое может быть выполнено только последовательно при нагрузке которую мы померить уже не можем. Посему зачастую и жертвуем производительностью перенося код в параллельный режим, копируя разные структуры в контексте потока и т.д и т.п. Посему и переносим нагрузку.
MSS>Признаки обвала скалабильности — разные. Не обязательно это трешинг на виртуальной памяти. Например, картина, когда на машине 100% CPU load, и показатель Processor Queue Length велик — это показания к апгрейду "камня" или увеличению количества "камней". С дисками примерно та же картина.
+1. Существует
Amdahl's law.
Добавление ресурса не дает 100% прибавки если ресурс не может быть использован параллельно. При 100% загрузке ресурса, мы можем сказать что ресурс хорошо распараллелен, и его расширение приведет к увеличению производительности.
GZ>>Все значительно сложнее. Поэтому я бы никогда не предлагал делать предварительную оптимизацию, а действовать только по факту с помощью нагрузочного тестирования и профайлера.
MSS>Ну очевидные вещи надо делать сразу, т.е. просто не делать глупостей изначально.
MSS>Что же касается оптимизации — то без цифр ее делать действительно нельзя. Не обязательно иметь профайлер, хватит чего-то вроде printf(GetSystemTimeAsFileTime()) из-под отладочного макроса.
MSS>Профайлер — скорее для оптимизации отдельно взятого вычислительного кода, а не для оптимизации систем в целом, тем более SQL-ориентированных.
Профайлер — это как пример инструмента. Определять лучше именно не гипотетически, а с помощью инструмента. (кстати, очень полезен стандартный Perfomance Monitor).
MSS>А вот анализатор SQL запросов — крайне полезен.
Посложнее. Зачастую вступают в действие внутренние механизмы БД — блокировки, триггеры, активность rollback сегмента и т.д. и т.п. Систему действительно надо смотреть в комплексе, и не одним анализатором.
Maxim S. Shatskih wrote:
> C>Кстати, еще один способ обрабатывать переполнение очереди — просто
> выбрасывать переполняющие пакеты.
> В низкоуровневых протоколах, которые либо заявлены как ненадежные (UDP),
> либо имеют ретрансмит (TCP) — это и делается.
> Но на уровне приложения? выдать юзеру "сервер перегружен, попробуйте
> позже" — это омерзительно.
Опять же, смотря где. При передаче аудио или видео, например, может быть
лучше выбросить полсекунды, а потом восстановиться, чем пытаться
полностью передать поток.
> C>Лимиты должны находится в "серверном" коде. Клиент должен либо
> блокироваться, либо получать EWOULDBLOCK'ом по зубам. Заниматься
> планированием нагрузки он не должен.
> Не всегда речь об архитектурах клиент-сервер. Часто речь о настольной
> апликации, которая на 100% грузит disk IO.
Я поэтому и взял слово "серверном" в кавычки — мы можем рассматривать
операционную систему как "сервер IO" с точки зрения приложения.
> MSS>>В какой это ОС у нас есть планировщик дискового IO? в виндах до
> Висты не было никакого, был только elevator seek и использование SCSI
> tagged queue, да и в Висте какой-то убогий.
> C>Ээээ... Linux (http://www.linuxjournal.com/article/6931
> И чего? примерно то же, что в виндах, разница в мелочи. Самое главное —
> в статье по ссылке нет понятия "IO приоритет процесса" и планирования
> дисковых реквестов в зависимости от того, кто их издал
Есть. Просто ты невнимательно смотришь.
Во-первых, есть ionice (
http://linux.die.net/man/1/ionice) — банально
менять приоритет.
Во-вторых, в более новых Линуксах для десктопных процессов можно
автоматом повышать приоритет планировщика.
В-третьих, ты сам можешь написать плугабельный user-space планировщик и
подключить его в ядро (там для этого фреймворк есть).
> ), Solaris, AIX? ionice в Линуксе так уже года четыре есть — использовал
> пару раз.
> А сколько народу у нас пишут под винды? а насколько портабелен такой код?
Кривость массовостью не оправдывается.
> C>Не сталкивался. Если бы столкнулся — настроил бы правила файрвола.
> То есть предполагается, что для работы вашей софтины юзер должен иметь
> файрволл? хороший подход для ляпов на коленке, плохой — для продукта.
Я вижу вообще только одно применение для явного ограничения траффика —
это всякие p2p-клиенты и скачивалки, которым иногда хочется обрезать
аппетит.
> C>И что дальше? Всем ставить Sleep(100) после каждого вызова ReadFile?
> Не всем, и не 100. Надо замерять, сколько времени выполнялись дисковые
> операции, каков незатротленный disk IO bandwidth, и на основании этого
> рассчитывать длительность каждого Sleep персонально. Иногда она может
> оказаться равной нулю, в коем случае вообще не надо звать Sleep.
Некрасиво. И не всегда работать будет — если я буду писать во
фрагментированый файл, то io bandwidth будет низким, а вот диск будет
занят на всю катушку.
> C>Может быть не процессор, а сеть, например (ее проще загрузить).
> Нет, с процессором у нас чуть иначе все. С процессором сложность в
> снятии адекватных статов его загрузки данной нитью. Снятие меток времени
> до и после CPU-bound кода — действительно идиотизм, ты прав. Тут нужен
> только и исключительно GetThreadTimes.
Это тоже идиотизм. В XP и Linux'е в результате можно сделать процесс,
сжирающий 100% процессорного времени, но при этом в статистике
системного времени он будет близок к нулю.
> C>Умные планировщики знают состояние ВСЕЙ системы и спокойно избегают
> таких случаев, а вот самопальный хак — самоспалится.
> Что вы предлагаете? для ограничения сетевого трафика, создаваемого
> софтом, обращаться к psched? какова цена реализации такого дела?
Как это сделано в Линуксе — в сетевых пакетах есть информация о том, кто
их засунул в стек. Соответственно, получить информацию о потоке — легче
легкого. Ну а дальше можно делать shaping и т.п.
Я согласен — Sleep может покрывать недостатки системы. Но его
"грязнохаковый" статус это ничуть не меняет. Нормальным инжинерным
решением было бы исправить саму операционную систему.
Posted via RSDN NNTP Server 2.1 beta
