su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Tengiz Kharatishvili                 2:5020/400     02 Jun 2001  06:47:17
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 "Lilya A. Kozlenko" <Lilya.A.Kozlenko@f17.n5025.z2.fidonet.org> wrote in
 message news:2931055731@mail.relex.ru...
 
 > Если все хорошо, то уже после 15-20 минут все  данные должны быть в
 
 памяти,
 
 > а потому и ввод-вывод должен сводиться к минимуму, что собственно и было
 > зарегистрировано посредством ms-ского монитора.
 >
 
 Страницы данных в памяти, однако, для журнала ведь это не так. Журнал же
 дёргается после каждой зафискированной транзакции, явной или неявной. SQL
 Server не имеет прямого group commit, а непрямой начинает сказыватся только
 при достаточно длинной очереди на запись в журнал, чего не бывает при
 наличии только двух пользователей для относительно коротких (по количеству
 байт, которые идут в журнал) транзакций. Вы ведь заметили аномалию уже после
 добавления второго пользователя?
 
 > Блокирование исключается. MS не держит share на страницы до конца
 > транзакции,
 
 Да, но только если уровень изоляции ниже repeatable read или если нет явного
 lock hint.
 
 > а intent у нее просто нет
 
 Если Вы имеете в виду, что SQL Server lock manager не имеет intent
 блокировок, то это не так. Мы с Вами ведь не о разных MS SQL Server-ах
 говорим? Или это очередное недоразумение?
 
 Hа всякий случай - справка для тех, кто не знает, но думает что знает:
 
 В MS SQL Server имеется нормальный многоуровневый lock manager, который
 реализует стандартный Granular Locking Protocol с некоторыми расширениями,
 специфическими для SQL Server. И для любого row-level lock всегда будет, как
 минимум, intent page lock и intent table lock.
 
 См. http://msdn.microsoft.com/library/psdk/sql/ac_8_con_7a_7xde.htm
 
 Чтобы убедиться в этом достаточно набрать следующее заклинание в isqlw
 (возможно, с точностью до констант):
 
 set transaction isolation level repeatable read begin tran
 select * from Northwind..[Order details]
 where OrderID = 10248 and ProductID = 11
 exec sp_lock @@spid
 rollback
 
 > Транзакции были
 > подобраны так, что "подраться" на блокировках им было трудно. Вероятность
 > блокировки не велика 2/1 000 000 и 2/10 000 000 именно столько данных было
 > в основной таблице банковских счетов (2 - это как раз счета,
 
 задействованные
 
 > при переводе денег). Пусть даже блокируется страница, ну сколько записей
 > фичически моглотам быть, ну пусть даже 20 в 8k поместилось, все равно это
 
 не
 
 > есть фактор, который мог бы существенно повлиять. Hе может получиться при
 > таком раскладе линейное подение. Значит, причина скорее всего не в
 > блокировании. Я даже на разные схемы (разные юзеры) разводила клиентов.
 > Hо этот тест не слишком честный - ведь объем держать надо больший,
 > а потому это так, в дополнение, и не больше.
 >
 
 Ваши рассуждения выглядели бы вполне убедительно при наличии конкретных
 данных о том, что на самом деле происходило с блокировками - это ведь только
 предположения, хотя и разумные, насколько я понимаю. Вы напрямую при помощи
 perfmon следили за блокировками? Вы смотрели, что там говорят
 sp_who/sp_who2/sp_lock и пр.?
 
 Пара слов в заключение:
 
 Крайне необычно, когда для более-менее приличной аппаратной системы
 суммарная производительность для двух пользователей практически равна
 производительности системы при наличии только одного пользователя, то есть
 пользователи аккуратно начинают делить ресурсы сервера поровну как только их
 становится > 1. Если, конечно, мониторинг ресурсов не показывает явного
 узкого места для первого же пользователя и если нет эффекта
 последовательного выполнения из-за каких-либо блокировок, простите за
 повторения.
 
 Типичной для многопользовательских систем является как раз обратная
 ситуация, когда суммарная производительность растёт при увеличении
 количества пользователей с одного до некоторого значения, при котором
 достигается максимальная суммарная производительность, зависящая от
 конкретной аппаратуры, схемы данных, конкретного приложения и пр. А при
 дальшейшем увеличении количества пользователей суммарная производительность
 уже только спадает. Речь, опять же, идёт об относительно простых OLTP
 транзакциях.
 
 Фокус при этом в том, что, например, начинает сказываться положительный
 эффект от group commit; от того, что страницы данных, которые нужны одному
 пользователю и которые попали в кеш, оказались нужны другим тоже и не нужена
 лишняя дисковая операция; от того, что система ввода/вывода при наличии
 большего количества запросов может за одну операцию записать больше данных
 (что быстрее, чем сделать несколько более коротких записей); от того, что на
 производительность операций с RAID дисками начинает благотворно влиять
 наличие параллельных запросов на ввод/вывод и многое другое.
 
 To my best knowledge, загадочной проблемы, которую Вы описываете, насколько
 я её понял, у SQL Server нет, во всяком случае это единственный известный
 мне случай такого в высшей степени непонятного поведения сервера при
 увеличении количества пользователей, выполняющих относительно простые OLTP
 транзакции. При условии, конечно, что анализ ситуации был произведён
 достаточно полно и глубоко, и что тестовое приложение было тщательно
 отлажено и настроено под повадки конкретной CУБД. Я уже высказался по этому
 поводу выше.
 
 В общем - загадка с Вашим тестовым приложением. Казалось бы - самый быстрый
 сервер базы данных согласно TPC-C (пусть даже и рекламному), и на тебе, на
 похожей задаче позорно проиграл, причём непонятно почему. Должна быть
 причина, и врядли она в сервере, просто не до конца копали, IMHO.
 
 Cheers.
 --- ifmail v.2.15dev5
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор