katit wrote:Короче это глупо так рассуждать.
Надо ставить SQL Server и все. Тогда будет точно известно что и как.
И если база то выяснится просто. И т.к. SQL Server умельцев достаточно то и если проблема там - то решим.
Я думаю что время потраченное на миграцию не будет большим по сравнению с временем что все тратят на разговоры.
Except for InnoDB and BDB storage engines, all locking in MySQL is deadlock-free for storage engines that use table-level locking. This include the MyISAM, MEMORY (HEAP), and ISAM engines. Deadlock avoidance is managed by always requesting all needed locks at once at the beginning of a query and always locking the tables in the same order
[/quote]Strannik223 wrote:Кое какая информация о особенностях блокировок MySQL.
http://dev.mysql.com/doc/mysql/en/Locking_Issues.html
Тенгиз, судя по тому что Борис сказал что тип базы не InnoDB, и по фразе из докиExcept for InnoDB and BDB storage engines, all locking in MySQL is deadlock-free for storage engines that use table-level locking. This include the MyISAM, MEMORY (HEAP), and ISAM engines. Deadlock avoidance is managed by always requesting all needed locks at once at the beginning of a query and always locking the tables in the same order
это не должен быть дедлок базы.
Я так понял что всюду table-lock используется.
Просто из любопытства, интересно что будет если перевести в InnoDB, там строчная блокировка, может полегчает?
Или BDB, там страничная.
vovap wrote:Это есть определяющий фактор. Я неоднократно об этом говорил. Вот, скажем, Вы как дальше собираетесь разбираться? Не знаете? И никто не знает. Потому как надо по-хорошему выяснять - а что делает MySQL в это время.
Strannik223 wrote:Тенгиз, судя по тому что Борис сказал что тип базы не InnoDB, и по фразе из доки ...<skipped>... это не должен быть дедлок базы. Я так понял что всюду table-lock используется. Просто из любопытства, интересно что будет если перевести в InnoDB, там строчная блокировка, может полегчает?
В принципе coarse lock granularity вполне может быть причиной конвоя. Я, конечно, не эксперт в MySQL, но одно время лазил по исходникам - никаких механизмов борьбы с конвоем там вроде как нет. InnoDB, вполне возможно, хорошо спроектированная система, но MySQL (опять таки - могу ошибаться) использует только часть ее функциональности, причем достаточно базовые вещи. Насчет масштабируемости / производительности BDB под Windows у меня тоже большие сомненияStrannik223 wrote:это не должен быть дедлок базы.
Я так понял что всюду table-lock используется.
Просто из любопытства, интересно что будет если перевести в InnoDB, там строчная блокировка, может полегчает?
Или BDB, там страничная.
, глядя как они реализуют "семафоры" в менеджере блокировок на Win32 API... Опять же anti-convoy logic там не реализована, система управления пулом страниц в памяти мне показалась достаточно примитивной... Вобщем, я бы выбрал MS SQL, особенно учитывая помощь Тенгиза. f_evgeny wrote:Ну вот, я и есть профессионал. И вот мое мнение: бесполезно о чем-либо разговаривать, пока система работает на CGI. Только избавившись от него, можно анализировать ситуацию. А с CGI ресурсы тратятся просто на запуск/уничтожение процессов.
tengiz wrote:f_evgeny wrote:Ну вот, я и есть профессионал. И вот мое мнение: бесполезно о чем-либо разговаривать, пока система работает на CGI. Только избавившись от него, можно анализировать ситуацию. А с CGI ресурсы тратятся просто на запуск/уничтожение процессов.
f_evgeny, логи не подтверждают Вашей гипотезы - затык и в первом и во втором случае "залипания" в выложенном логе произошёл из за того, что было запущено слишком много экземпляров PHP. Если бы проблема была в долгом их запуске, то картина выглядела бы совершенно иначе: мы бы видели зашкал CPU как раз в коде ядра, а пользовательские процессы, включая PHP, MySQL, IIS сидели бы и сосали лапу. Однако в реальности всё было иначе - в первом "залипании" CPU вообще ушёл в 0, во втором, MySQL (в основном) и PHP весело шуршали на пару. Да только не над тем, над чем надо.
А вообще, пожалуйста, читайте внимательно то, что пишут другие профессионалы. Демонстративное игнорирование чужого, причём, аргументированного, мнения - совершенно непрофессионально.
f_evgeny wrote:Если в машине три колеса нормальные, а одно - от детского велосипеда, то прежде чем обмениваться мнениями по глубокомысленным вопросам, есть все-таки смысл заменить детское колесо, а потом уже смотреть мотор.
tengiz wrote:f_evgeny wrote:Если в машине три колеса нормальные, а одно - от детского велосипеда, то прежде чем обмениваться мнениями по глубокомысленным вопросам, есть все-таки смысл заменить детское колесо, а потом уже смотреть мотор.
Под детским велосипедом имеется в виду MySQL? Или это скорее инвалидная коляска?
P.S. Прежде чем менять колесо нужно хотя бы попытаться понять, что же на самом деле происходит.
P.P.S. Фрагмент из бородатого автомобильного анекдота: А ты капот открывал? Да. А по колесу стучал? Стучал. Ну тогда не знаю, что и делать.
P.P.P.S. Отчего же они - в смысле братцы-опенсорсники - такие постоянно сердитые
.
. Ну я понимаю, что Вам ненавистно слово, Микрософт, но не только Вам. Наш CEO Ed Zander, который прилетал из Чикаго сегодня потoлковать со Стивом Балмером, и заодно заскочил к нам на 30 минут что бы встретится с народом, тоже Микрософт не любит, так что Вы в хорошей компании, не волнуйтись. Ну нету у нас человека из Oracle Engine, нету, так что прийдется воспользоватся знаниями Тенгиза. Siberian Cableman wrote:Ключевой вопрос как ставнивать половины: vasjapupkin.com и microsoft.com используют MySQL и MSSQL соответственно, так что можно сделать вывод что 50% компаний из нашего списка используют MySQL
А если по делу, Евгений поверьте Тенгизу, ему по роду службы надо уметь распутывать подобные вещи. У него уже глаз набит на это. К тому же у него есть лог, чего у Вас нету