Сервер для Привета

vovap · Post by **vovap** » 28 Apr 2004 02:17

Privet wrote:Я в чудеса не очень верю. Вряд ли SQL запросы из PHP от апача отличаются от IIS. Все индикаторы показывают, что встаёт именно MySQL. Таблицы заблокированы и SQL запросы выстроились в очередь на выполнение.

А шо, получил tengiz логи?

И что это за антинаучные эксперименты с 2 WEB серверами? Никакого толкового результата так все равно не получить. Что мешает поставить на новый бокс и WEB и базу, запустить на него отдельно стоящего тестики - а потом все снести и хоть диск форматировать.

Strannik223 · Post by **Strannik223** » 28 Apr 2004 02:38

Privet wrote:Я в чудеса не очень верю. Вряд ли SQL запросы из PHP от апача отличаются от IIS. Все индикаторы показывают, что встаёт именно MySQL. Таблицы заблокированы и SQL запросы выстроились в очередь на выполнение. Apache в этом отношении изменить ничего не может. Некоторое повышение производительности за счет более быстрого старта PHP вряд ли будет особенно заметно при нагрузке.

Can it be a deadlock?

Post by **Privet** » 28 Apr 2004 03:46

vovap, логи за тот период ничем помочь пока не могут. Сегодня я запустил лог по новой. Эксперимент с апачем практически ничего не стоит.

Сейчвс вставляю новые процессоры и бум смотреть, что получилось. Первая неприятность оказалась в том, что RAID - контроллер оказался слишком длинным. Конструкция этого ящика не позволяет вставлять платы такой дляны. Придётся пилить...

Третий диск из сервера я уже вынул и всё перекачал на два оставшихся, поэтому на самое ближайшее время никаких остановов не предвидится.

Post by **Privet** » 28 Apr 2004 06:19

Strannik223 wrote:....
Can it be a deadlock?

Вряд ли. Deadlock никогда не рассасывается. Два процесса мёртво держат друг друга за глотку. Во всяком случае это моё понимание как программиста. Может быть, в терминах баз денных это означает иное.
На форуме же перегрузка потихоньку по мере выполнения запросов рассасывается. Это хорошо видно в администраторе.

Каких-то непонятностей здесь нет. Вопрос в том какие запросы зависают и как их оптимизировать. Тот администратор, каким я пользуюсь не позхволяет мне оперативно смотреть какие запросы вмсят. Он показывает только первые несколько символов SELECT * FROM ..." и всё. Угадать какие это запросы с определённой степенью вероятности можно. Я поленился это сделать в своё время, т.к. для меня эта информация мало что значит. Оптимизировать запросы я не умею.
Сейчас некоторая проблема ещё в том, что большинство проблем случается в моменты, когда меня нет дома. Сейчас идёт запись в лог, но его результаты мне и так хорошо известы. Много нового я не жду. Процессор перегружается MySQL. Искать надо конкретно там. Таблици и запросы не являются секретом. Определю где - выложу на сайт.

f_evgeny · Post by **f_evgeny** » 28 Apr 2004 06:34

Privet wrote:f_evgeny, почему именно на 80-й? Я и сейчас могу видеть распределение нагрузки. Или Вы что-то другое имели ввиду?

Я имею в виду то, что после переключения Apache на 80-й порт, основная нагрузка ляжет на него и он будет испытываться в боевых условиях, поскольку подавляющее большинство клиентов будет коннектиться через него.
Сегодняшняя конфигурация (IIS:80, Apache:1333), хороша тем, что можно спокойно проверить работоспособность. Но по настоящему оценить поможет ли Вам переезд на Apache/module можно только после того, как вся нагрузка пойдет через Apache.
Я думаю есть немаленькая вероятность того, что ресурсы съедает запуск CGI на IIS, а не хватает их базе и выглядит это так как будто затыкается именно база. Хотя ответ можгут дать только испытания в полевых условиях.

tengiz · Post by **tengiz** » 28 Apr 2004 08:09

Privet wrote:Вряд ли. Deadlock никогда не рассасывается. Два процесса мёртво держат друг друга за глотку. Во всяком случае это моё понимание как программиста. Может быть, в терминах баз денных это означает иное. На форуме же перегрузка потихоньку по мере выполнения запросов рассасывается. Это хорошо видно в администраторе.

Это зависит от того, есть ли в MySQL автоматическое детектирование дедлоков - тут вроде у есть люди, имеющие реальный опыт работы с этим продуктом, для них это должно быть элементарным вопросом. Системы без такового обычно имеют таймаут, после чего дедлок через некоторое время разрешается сам собой. Но обычно дедлок не сопровождатется зашкалом CPU. И если же я правильно понял, что как раз именно это и имеет место быть. Тогда это может быть "convoy phenomena" - неприятное явление, хорошо известное в базах данных аж с начала 70-х и причиной которого является неаккуратное (хотя и функционально 100% правильное) программирование синхронизации доступа к очень активно используемому ресурсу. Все "главные" современные СУБД (MySQL excluded - ничего про него не знаю) этой проблемы не имеют, потому что заведомо проектируются так, чтобы её избежать.

<added>

Полез на сайт MySQL.com и нашёл, что если в качестве подсистемы хранинения и обработки транзакций использовать ещё одно финское техническо чудо - InnoDB (которое его автор лет 5 назад пытался поочерёдно продать Oracle, IBM и MS) - то MySQL действительно имет автоматическое разрешение дедлоков. Я уже много хорошего слышал про этот InnoDB, парень, который его делал видимо достаточно грамотен. Однако про конвои на их сайте нет ничего. Оно, конечно, может ровным счётом не означать, но тем не менее...

</added>

<added more>

After a little more googling...

Surely enough Heikki Tuuri - the guy who wrote the InnoDB Engine - is very well aware of the convoy problem and does know a fact or two about the internal mechanics of MS SQL Server, including the UMS - UserModeScheduler. However, аccording to the following, InnoDB doesn't appear to employ any real anti-convoy techniques, except some hard-coded threading-related limits:

http://www.distlab.dk/mysql-4.1/html/sr ... ource.html

Which makes me believe that the most popular storage engine that comes with MySQL and that is bound to be much simpler than more "advanced" InnoDB would hardly be convoy-aware at all.

</added more>

f_evgeny · Post by **f_evgeny** » 28 Apr 2004 19:10

Новости с фронтов?

Post by **Privet** » 29 Apr 2004 02:47

Palych wrote:
Privet wrote:Таблицы заблокированы...

Oni tochno zablokirovany, ili mysql prosto pozhiraet resursy?

Если верить winmysqladmin, то заблокированы (locked).

Я очень скромно оцениваю свои способности правильно интерпретировать информация от администратора. Любые советы где и что посмотреть принимаются.

Лог сегодня постараюсь посмотреть и выделить кризисные места.

Сервер собрал, но пока не заводится и издаёт ужсающий звук (зуммер).
Монитор в основном не заводится. Только два раза получил сообщение CMOS Error. Проверка RAM - ок. Unknown processor 2133.
В настройки войти не удалось.

Вчера скачал документацию, сегодня буду смотреть, проверять перемычки и пр.

Кто бы мне объяснил что такое unbuffered DDR и как её отличить от buffered?

SBolgov · Post by **SBolgov** » 29 Apr 2004 03:08

Privet wrote:Кто бы мне объяснил что такое unbuffered DDR и как её отличить от buffered?

Личного опыта, к сожалению, нет, но по информации с "железячных" сайтов:

На примитивном уровне: unbuffered - это "обычная", buffered или registered - для серверов. Не все чипсеты поддерживают работу с buffered модулями. (Ваш - AMD 762 - поддерживает.)

Судя по описанию Вашей материнки на сайте производителя, она поддерживает ТОЛЬКО registered модули.

Вот что мне удалось накопать в достаточно старом FAQ по компьютерной памяти ( http://www.ixbt.com/mainboard/memgloss.html ):

unbuffered

буферизованных

registered

buffered

ключей

key

Отсюда можно сделать вывод, что buffered и unbuffered DIMM отличаются расположением вырезов в нижней части модуля.

Кто знает лучше - поправьте меня, пожалуйста.

SBolgov · Post by **SBolgov** » 29 Apr 2004 03:33

SBolgov wrote:Судя по описанию Вашей материнки на сайте производителя, она поддерживает ТОЛЬКО registered модули.

Ой, вру. Похоже, "обычные" она тоже поддерживает, но "обычными" нельзя набить максимальный объём - 4ГБ.

Насколько я помню, "обычные" поддерживаются, но ими нельзя заполнить все 4 слота DIMM. Если хочется заполнить все 4, то все модули памяти должны быть registered.

К сожалению, точную ссылку найти пока не могу. :pain1:

SBolgov · Post by **SBolgov** » 29 Apr 2004 03:45

Вот, накопал статью о Registered DIMM. Рассказывает о SDRAM Registered DIMM и DDR SDRAM Registered DIMM. Судя по картинке - Registered DDR модули имеют один "вырез" внизу, а не два, как "обычные". И, естественно, есть различия в маркировке модулей.

См. в конце статьи последний абзац перед "Заключением":

m — тип используемого модуля памяти (R — Registered, U - Unbuffered)

Post by **Privet** » 29 Apr 2004 05:27

Лог передан для анализу tengiz и ещё некоторым участникам. Публиковать его открыто я бы не хотел.

Первые сюрпризы (для меня) уже есть. Причина блокировки процессора - нехватка памяти. Пока я не могу сказать какой процесс (процессы) забирают памаять. Вполне возможно, что версия f_evgeny верна.

Post by **Privet** » 29 Apr 2004 06:00

На памяти написано:

Наклейки:

Code: Select all

A4303293 MEMORY, DDR333
512MB                              2201
8N:X005202146         5000004332

Code: Select all

64X64      64X64dBOc8nAVA333
DDR333  12210010033031504ds

Чип:

AVANT
S80064YMTW - GX

Что бы это значило?

Post by **Privet** » 29 Apr 2004 06:36

Я допускал несколько грубых ошибок в интерпретации счетчиков. Главный показатель памати я смотрел - comitted memory, что никогда не превышало критических значений. На самом деле оказалось, что Available memory в некоторых случаях близко к нулю.

Тем не менее считать, что проблема решена слишком рано. Я бы попросил высказаться профи.
Расход памяти нарастает очень быстро. Установка дополнительных модулей мало, что даст, да и некуда их ставить. Основной сервер имеет всего два слота, которые уже заняты (2х512).
Надо искать причину такого лавинообразного роста потребной памяти. Я запустил лог опять и дополнил счетчики Working Set на все процессы, чтобы посмотреть какие процессы требуют память.
tengiz, одобрямс?

Волчара · Post by **Волчара** » 29 Apr 2004 07:09

я и так могу сказать. Это апач 1.3 и его prefork model, когда запускается один child на каждые 10-100 запросов. Каждый чайлд кушает нехреново памяти

На винде апач надо скомпилировать с mpm_winnt, должно помочь. Только надо сначала проверить совместимость этого модуля с php

Для начала можно немного поиграться с конфигом prefork модуля, тоже поможет

А может на винде mpm стандартно идет... я никогда не читал подробно. В общем смотреть конфиг этих модулей