Каталог документации / Раздел "Базы данных, SQL" / Оглавление документа

6 Замечания по портированию пакета на другие системы

Работающая библиотека потоков Posix необходима для сервера. В Solaris 2.5 мы используем Sun PThreads (местная поддержка потоков в 2.4 и более ранних версиях недостаточно хороша), а на Linux применен LinuxThreads (автор: Xavier Leroy, Xavier.Leroy@inria.fr).

Трудно выполнить перенос к новому Unix-варианту без хорошей местной поддержки потоков. Здесь может пригодиться пакет MIT-pthreads. Подробности в mit-pthreads/README и по адресу http://www.humanfactor.com/pthreads.

Дистрибутив MySQL включает исправленную версию Pthreads из MIT (с адреса http://www.mit.edu:8001/people/proven/pthreads.html). Это может использоваться для некоторых операционных систем, которые не имеют поддержки потоков в стандарте POSIX.

Также возможно использовать другой пакет уровня пользователя FSU Pthreads (подробности на http://www.informatik.hu-berlin.de/~mueller/pthreads.html). Эта реализация используется для SCO.

Пакет нуждается в компиляторе C++ (авторы применяют gcc и пробовали SparcWorks). Другой транслятор, который, как известно, работает, Irix cc.

Чтобы откомпилировать только клиента, вызовите ./configure --without-server.

Не имеется в настоящее время никакой поддержки для компиляции только сервера, поскольку мало где это бывает нужно.

Если Вы должны переделать любой файл Makefile или скрипт конфигурации, Вы должны получить Automake и Autoconf. Авторы использовали automake-1.2 и autoconf-2.12.

Теперь можно браться за дело:

/bin/rm */.deps/*.P
/bin/rm -f confi6.cache
aclocal
autoheader
aclocal
automake
autoconf
./configure --with-debug=full --prefix='your installation directory'

# The makefiles generated above need GNU make 3.75 or newer.
# (called gmake below)
gmake clean all install init-db

Если Вы сталкиваетесь с проблемами, Вам, вероятно, придется делать некоторую отладку MySQL! Подробности в разделе "6.1 Отладка сервера MySQL".

ОБРАТИТЕ ВНИМАНИЕ: Прежде, чем Вы начнете отлаживать mysqld, сначала заставьте работать программы mysys/thr_alarm и mysys/thr_lock. Это гарантирует, что Ваша установка потоков работоспособна!

6.1 Отладка сервера MySQL

Если Вы используете некоторые функциональные возможности, которые являются очень новыми в MySQL, Вы можете пробовать выполнять mysqld с опцией --skip-new (которая отключит все новые, потенциально опасные, функциональные возможности) или с --safe-mode, которая отключает много оптимизации, которая может вызывать проблемы.

Если mysqld не хочет запускаться, Вы должны проверить, что Вы не имеете любые файлы my.cnf, которые сталкиваются с Вашей установкой! Вы можете проверять параметры my.cnf с помощью вызова mysqld --print-defaults и избегать их использования, запуская mysqld --no-defaults ....

Если mysqld начинает сильно загружать CPU или память, или он виснет, Вы можете использовать mysqladmin processlist status, чтобы выяснить, выполняет ли кто-то запрос, который берет длительное время. Стоит выполнить mysqladmin -i10 processlist status, если Вы испытываете проблемы с эффективностью работы, или когда новый клиент не может соединиться с сервером, а остальные работают нормально.

Команда mysqladmin debug сбрасывает в дамп некоторую информацию относительно блокировок в использовании, занятой памяти и запросов. Это может помочь решить некоторые проблемы. Эта команда также обеспечивает некоторую полезную информацию, даже если Вы не компилировали MySQL для отладки!

Если проблема состоит в том, что некоторые таблицы сильно замедляются, Вы должны попробовать оптимизировать таблицу с помощью команды OPTIMIZE TABLE или вызова утилиты myisamchk. Подробности в разделе "4 Администрирование СУБД MySQL". Вы должны также проверить медленные запросы командой EXPLAIN.

Вы должны также прочитать OS-специфический раздел в этом руководстве для изучения проблем, которые могут быть уникальными для Вашей среды. Подробности в разделе "2.6 Замечания по отдельным операционным системам".

6.1.1 Компиляция MYSQL для отладки

Если Вы имеете некоторые очень специфические проблемы, Вы можете всегда попробовать отлаживать MySQL. Чтобы сделать это, Вы должны конфигурировать MySQL с опциями --with-debug или --with-debug=full. Вы можете проверять, компилировался или нет MySQL с отладкой, командой mysqld --help. Если аргумент --debug перечислен с параметрами, то Вы имеете допускаемую отладку. Команда mysqladmin ver также вносит в список версию mysqld как mysql ... --debug в этом случае.

Если Вы используете gcc или egcs, рекомендуемая строка выбора конфигурации:

CC=gcc CFLAGS="-O2" CXX=gcc
CXXFLAGS="-O2 -felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --with-debug \
            --with-extra-charsets=complex

Это позволит избежать проблемы с библиотекой libstdc++ и исключительными ситуациями в C++ (много трансляторов имеют проблемы с ними), и откомпилирует версию MySQL с поддержкой для всех наборов символов.

Если Вы подозреваете ошибку перекрытия памяти, Вы можете конфигурировать MySQL с опцией --with-debug=full, которая установит проверку распределения памяти (SAFEMALLOC). Однако, работа с SAFEMALLOC очень медленная, так что, если Вы получаете проблемы эффективности, Вы должны запустить mysqld с опцией --skip-safemalloc. Это отключит проверку памяти для всех обращений к malloc и free.

Если mysqld валится, когда Вы компилируете его с опцией --with-debug, Вы, вероятно, нашли ошибку транслятора или ошибку синхронизации внутри MySQL. В этом случае Вы можете попробовать добавить -g к переменным CFLAGS и CXXFLAGS и не использовать --with-debug. Если mysqld теперь все равно валится, Вы можете по крайней мере присоединяться к нему с помощью gdb или использовать gdb на файле дампа, чтобы выяснить, что же там случилось.

Когда Вы конфигурируете MySQL для отладки, автоматически допускаются много функций проверки безопасности, которые контролируют здоровье mysqld. Если они находят что-то непредвиденное, сообщение будет записано в stderr, который safe_mysqld направляет к файлу регистрации ошибок! Это также означает, что, если Вы имеете некоторые непредвиденные проблемы с MySQL и используете дистрибутив исходников, Вы должны конфигурировать MySQL для отладки!

В Windows MySQL mysqld.exe по умолчанию компилируется с поддержкой для файлов трассировки.

6.1.2 Создание файлов трассировки

Если сервер mysqld не запускается, или если Вы можете заставить его очень быстро рухнуть, Вы можете попробовать создать файл трассировки, чтобы найти проблему.

Чтобы сделать это, Вы должны иметь mysqld, который компилировался для отладки. Вы можете проверять это, выполняя mysqld -V. Если номер версии заканчивается -debug, она компилировалась с поддержкой для файлов трассировки.

Запустите сервер mysqld с протоколом трассировки в /tmp/mysqld.trace (или в C:\mysqld.trace под Windows):

mysqld --debug

Под Windows Вы должны также использовать параметр --standalone, чтобы не запустить mysqld как сервис:

В DOS-окне введите:

mysqld --debug --standalone

После этого Вы можете использовать инструмент командной строки mysql.exe во втором окне DOS, чтобы воспроизвести проблему. Вы можете завершить вышеупомянутый сервер mysqld с помощью вызова команды mysqladmin shutdown.

Обратите внимание, что файл трассировки станет очень БОЛЬШИМ! Если Вы хотите иметь меньший файл трассировки, Вы можете использовать вызов:

mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace

Это печатает только информацию с наиболее интересными отметками в /tmp/mysqld.trace.

Если Вы делаете отчет об ошибке относительно этой ситуации, пожалуйста, пошлите в соответствующий список рассылки только те строки из файла трассировки, в которых, кажется, что-то идет неправильно! Если Вы не можете локализовать неправильное место, Вы можете закачать по ftp весь файл трассировки вместе с полным отчетом ошибки на ftp://support.mysql.com/pub/mysql/secret, чтобы разработчики MySQL могли посмотреть это детально.

Файл трассировки сделан с применением пакета DBUG (автор Fred Fish). Подробности в разделе "6.3 Пакет DBUG".

6.1.3 Использование mysqld под gdb

На большинстве систем Вы можете также запустить mysqld из gdb, чтобы получить большее количество информации, если mysqld терпит крах.

С несколькими старыми версиями gdb под Linux Вы должны использовать run --one-thread, если Вы хотите отладить потоки mysqld. В этом случае Вы можете иметь только один активный поток в каждый момент времени.

При запуске mysqld под gdb, Вы должны отключить трассировку стека с помощью опции --skip-stack-trace, чтобы быть способными захватить segfaults внутри gdb.

Очень сложно отладить MySQL под gdb, если Вы делаете много новых подключений в то время, как gdb не освобождает память для старых потоков. Вы можете избегать этой проблемы, запуская mysqld с параметром -O thread_cache_size=max_connections+1. В большинстве случаев помогает только использование using -O thread_cache_size=5!

Если Вы хотите получать дамп на Linux, если mysqld падает с сигналом SIGSEGV, Вы можете запустить mysqld с опцией --core-file. Файл дампа может использоваться, чтобы сделать обратную трассировку (backtrace), которая может помочь Вам выяснить, почему именно mysqld все же рухнул:

shell> gdb mysqld core
gdb>   backtrace full
gdb>   exit

Подробности в разделе "8.4.1 Что делать, если MySQL рушится".

Если Вы используете gdb 4.17.x или выше под Linux, Вы должны установить файл .gdb со следующей информацией, в Вашем текущем каталоге:

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

Если Вы имеете проблемы при отладке потоков с gdb, Вы должны загрузить gdb 5.x и попробовать применить эту версию. Новая реализация gdb очень сильно улучшила обработку потоков!

Имеется пример, как отладить mysqld:

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # Do this when mysqld crashes

Включите вышеупомянутый вывод в почту, сгенерированную mysqlbug и отправьте на mysql@lists.mysql.com.

Если mysqld висит, Вы можете попробовать использовать некоторые инструментальные средства системы подобно strace или /usr/proc/bin/pstack, чтобы исследовать, где mysqld завис:

strace /tmp/log libexec/mysqld

Если Вы используете интерфейс Perl DBI, Вы можете включить информацию об отладке, используя метод trace или устанавливая системную переменную DBI_TRACE.

6.1.4 Использование трассировки стека

На некоторых операционных системах, файл регистрации ошибок будет содержать трассировку стека, если mysqld неожиданно рушится. Вы можете использовать это, чтобы выяснить, где (и возможно, почему) рухнул mysqld. Подробности в разделе " 4.9.1 Протокол ошибок". Чтобы получать трассировку стека, Вы не должны компилировать mysqld с опцией -fomit-frame-pointer при использовании gcc. Подробности в разделе "6.1.1 Компиляция MYSQL для отладки".

Если файл ошибок содержит нечто вроде следующего:

mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that
may help in finding out why mysqld died
Attemping backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong stack range sanity check, ok, backtrace follows
0x40077552
0x81281a0
0x8128f47
0x8127be0
0x8127995
0x8104947
0x80ff28f
0x810131b
0x80ee4bc
0x80c3c91
0x80c6b43
0x80c1fd9
0x80c1686

Вы можете найти, где именно mysqld рухнул, следующим образом:

Скопируйте вышеупомянутые числа в файл, например, в mysqld.stack.
Сделайте файл символа для сервера mysqld:
```
nm -n libexec/mysqld > /tmp/mysqld.sym
```
Обратите внимание, что многие двоичные дистрибутивы MySQL приходят уже с вышеупомянутым файлом, именованным mysqld.sym.gz. В этом случае Вы должны распаковать его командой:
```
gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
```
Выполните:
```
resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack
```
Это распечатает, где mysqld взорвался. Если это не помогает Вам выяснить, почему произошла такая неприятность, Вы должны сделать сообщение об ошибке и включать вывод из вышеупомянутого в отчет об ошибке. Обратите внимание, однако, что в большинстве случаев это не будет помогать авторам найти причину проблемы. Чтобы локализовать глюк в большинстве случаев нужно знать запрос, который уничтожил mysqld и предпочтительно иметь тестовый пример так, чтобы авторы смогли повторить проблему! Подробности в разделе "1.4.1 Как сообщать об ошибках или проблемах".

6.1.5 Использование журналов, чтобы найти причину ошибок в mysqld

Обратите внимание, что перед стартом mysqld с опцией --log Вы должны проверить все Ваши таблицы с помощью myisamchk. Подробности в разделе "4 Администрирование СУБД MySQL".

Если mysqld падает или виснет, Вы должны запустить mysqld с опцией --log. Когда mysqld в очередной раз свалится, Вы можете исследовать конец журнала для выявления запроса, который уничтожил mysqld.

Если Вы используете --log без имени файла, файл регистрации будет сохранен в каталоге баз данных как 'hostname'.lo6. Обычно проблема заключена в последнем запросе в журнале, но если возможно, проверьте это, перезапуская mysqld и выполняя найденный запрос из инструментальных средств командной строки mysql. Если запрос работает нормально, Вы должны также проверить все сложные запросы, которые не завершались на момент падения сервера.

Вы можете также попробовать команду EXPLAIN на всех инструкциях SELECT, которые берут длительное время, чтобы гарантировать, что mysqld использует индексы правильно. Подробности в разделе "5.2.1 Синтаксис EXPLAIN (получение информации о SELECT)".

Вы можете находить запросы, которые берут длительное время, запуская mysqld с опцией --log-slow-queries. Подробности в разделе "4.9.5 Медленный файл регистрации".

Если Вы находите текст mysqld restarted в файле регистрации ошибок (обычно hostname.err), Вы, вероятно, нашли запрос, который заставляет mysqld падать. Если это случается, Вы должны проверить все Ваши таблицы с помощью myisamchk (подробности в разделе "4 Администрирование СУБД MySQL"), и проверить запросы в журналах MySQL, чтобы видеть, все ли работает. Если Вы находите запрос, который не намерен выполняться, попробуйте сначала обновиться до самой новой версии MySQL. Если это не помогает, и Вы не можете найти ничего подходящего в архиве рассылок mysql, Вы должны сообщить ошибку на mysql@lists.mysql.com. Ссылки на архив рассылок доступны на страничке http://www.mysql.com/documentation.

Если Вы запустили mysqld с аргументом --with-myisam-recover, MySQL автоматически проверит и попробует отремонтировать таблицы MyISAM, если они отмечены как 'not closed properly' или 'crashed'. Если это случается, MySQL будет писать соответствующую метку в файл hostname.err: 'Warning: Checking table ...', которая сопровождается записью: Warning: Repairing table, если таблица должна быть восстановлена. Если Вы получаете много этих ошибок, без предыдущего падения mysqld, то что-то идет неправильно и должно быть исследовано далее.

Конечно, не хороший знак, если mysqld падает неожиданно, но в этом случае надо поискать причину его падения, а не причину появления заметки Checking table... в файле протокола.

6.1.6 Создание случая теста, когда Вы испытываете искажение таблицы

Если Вы получаете разрушенные таблицы, или если mysqld всегда терпит неудачу после некоторых команд модификации, Вы можете проверить воспроизводимость ситуации, делая следующее:

Завершите сервер MySQL (командой mysqladmin shutdown).
Сделайте копию таблиц (чтобы принять меры против самого маловероятного случая, что ремонт будет невозможен).
Проверьте все таблицы с помощью myisamchk -s database/*.MYI. Восстановите любые неправильные таблицы командой myisamchk -r database/table.MYI.
Сделайте вторую копию таблиц.
Удалите (или переместите подальше) любые старые журналы из каталога данных MySQL, если Вы нуждаетесь в большем количестве места на диске.
Запустите mysqld с аргументом --log-binary. Если Вы хотите находить запрос, который разрушает mysqld, Вы должны использовать --log --log-binary.
Когда Вы получили разрушенную таблицу, остановите mysqld.
Восстановите из копии.
Перезапустите сервер mysqld без параметра --log-binary.
Заново выполните команды с помощью mysqlbinlog update-log-file|mysql. Файл регистрации модификации сохранен в MySQL каталоге баз данных под именем hostname-bin.#.
Если таблицы снова разрушены, или Вы можете достичь разрушения mysqld с вышеупомянутой командой, Вы нашли восстанавливаемую ошибку, которая должна быть проста в устранении! Закачайте таблицы и двоичный файл регистрации по FTP на ftp://support.mysql.com/pub/mysql/secret и сообщите об ошибке на bugs@lists.mysql.com, чтобы проинформировать об имеющейся проблеме, и группа разработчиков MySQL устранит ее как можно скорее.

Вы можете также использовать скрипт mysql_find_rows, чтобы выполнить только некоторые из инструкций, если Вы хотите сузить проблему.

6.2 Отладка клиента MySQL

Чтобы отладить клиента MySQL с интегрированным пакетом отладки, Вы должны конфигурировать MySQL с опциями --with-debug или --with-debug=full. Подробности в разделе "2.3.3 Типичные опции скрипта configure".

Перед запуском клиента Вы должны установить системную переменную MYSQL_DEBUG:

shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace
shell> export MYSQL_DEBUG

Это заставляет клиентуру генерировать файл трассировки в /tmp/client.trace.

Если Вы имеете проблемы с Вашим собственным кодом клиента, Вы должны пытаться соединиться с сервером и выполнить Ваш запрос, используя клиента, который, как известно, точно работает. Это делается запуском mysql в режиме отладки (предполагается, что Вы компилировали MySQL с поддержкой режима отладки):

shell> mysql --debug=d:t:O,/tmp/client.trace

Это обеспечит полезную информацию в случае, если Вы отправляете по почте отчет об ошибке. Подробней процесс рассмотрен в главе "1.4.1 Как сообщать об ошибках и проблемах ".

Если Ваш клиент терпит крах в некотором коде, который выглядит абсолютно нормальным, Вы должны проверить, что Ваш включаемый файл mysql.h соответствует Вашему библиотечному файлу mysql. Очень частая ошибка: пытаются использовать старый файл mysql.h из старой установки с новой библиотекой MySQL.

6.3 Пакет DBU6

Сервер и многие клиенты MySQL компилируются с пакетом DBUG, первоначально сделанным Fred Fish. Когда MySQL сконфигурирован для отладки, этот пакет делает возможным доступ к файлу трассировки. Подробности в разделе "6.1.2 Создание файлов трассировки ".

Для использования пакета отладки, вызовите программу с опцией --debug="..." или -#....

Большинство программ MySQL имеет заданную по умолчанию строку отладки, которая будет использоваться, если Вы не определяете опцию --debug. Заданный по умолчанию файл трассировки обычно /tmp/programname.trace в Unix или \programname.trace под Windows.

Строка управления отладкой представляет собой следующую последовательность полей, отделяемых двоеточиями:

<field_1>:<field_2>:...:<field_N>

Каждое поле состоит из обязательного символа флажка, сопровождаемого факультативной "," и разделяемым запятыми списком модификаторов:

flag[,modifier,modifier,...,modifier]

В настоящее время распознанные символы флажка:

d	Включить вывод из макроса DBUG_<N> для текущего состояния. Может сопровождаться списком ключевых слов, который выбирает вывод только для макрокоманд DBUG с тем же самым ключевым словом. Пустой список ключевых слов подразумевает вывод для всех макрокоманд.
D	Задержка после каждой линии вывода отладчика. Параметр указывает число десятых долей секунды для задержки. То есть, `-#D,20` задает задержку в две секунды.
f	Ограничивает отладку и/или трассировку списком имен функций. Обратите внимание, что пустой список отключит все функции. Соответствующий флажок "d" или "t" должен все же быть дан, поскольку этот флажок только ограничивает их действие, если они включены.
F	Идентифицируют имя исходного файла для каждой строки отладки или трассирует вывод.
i	Идентифицируют процесс с pid для каждой строки отладки или трассирует вывод.
g	Включить профилирование. Создайте файл 'dbugmon.out', содержащий информацию, которая может использоваться, чтобы профилировать программу. Может сопровождаться списком ключевых слов, которые выбирают профилирование только для функций в этом списке. Пустой список подразумевает, что все функции подлежат профилированию.
L	Идентифицирует номер строки исходного файла для каждой строки отладки или трассирует вывод.
n	Выводит текущую глубину вложенности функции для каждой строки отладки или трассирует вывод.
N	Номер каждой строки вывода dbu6.
o	Переназначает выходной поток отладчика в файл. По умолчанию задан вывод в stderr.
O	То же, что и `O`, но файл сбрасывается между записями. То есть, после каждой записи файл закрывается, и снова открывается только перед следующей записью. Тормозит, конечно, кошмарно, но зато гарантирует сохранность данных в этом файле на случай слета системы. Что при отладке не бесполезно...
p	Ограничивает действия отладчика определенными процессами. Процесс должен быть указан в макросе DBUG_PROCESS и совпадать с одной из записей в списке действий отладчика.
P	Выводит имя текущего процесса для каждой строки отладки или трассирует вывод.
r	При установке нового состояния отладки не наследует предыдущее состояние вложенности функции. Полезно, когда вывод должен начаться в левом поле.
S	Функция _sanity(_file_,_line_) для каждой отлаживаемой функции до _sanity() возвращает отличное от 0 значение. Обычно используется с safemalloc. Как задается это значение, и что оно вообще значит в документации не сказано, а опытным путем это установить не удалось.
t	Включить функцию трассировки строк вызова и выхода (call/exit). Может сопровождаться списком, содержащим номер максимального уровня трассировки, вне которого никакого вывода не произойдет для отладочных или трассировочных макрокоманд. Умолчание задается при компиляции.

Некоторые примеры строк управления отладкой:

-#d:t
-#d:f,main,subr1:F:L:t,20
-#d,input,output,files:n
-#d:t:i:O,\\mysqld.trace

В MySQL общие тэги для печати (с опцией d) такие: enter, exit, error, warning, info и loop.

6.4 Методы для блокировки

В настоящее время MySQL поддерживает блокировку таблицы только для типов таблиц ISAM/MyISAM и HEAP, а также блокировки уровня страницы для таблиц BDB. Подробности в разделе "5.3.1 Как MySQL блокирует таблицы". При работе с таблицами MyISAM можно свободно смешивать INSERT и SELECT без блокировок (Versioning).

Начиная с версии 3.23.33, Вы можете анализировать появление блокировки таблицы на Вашей системе, проверяя системные переменные Table_locks_waited и Table_locks_immediate.

Некоторые пользователи базы данных утверждают, что MySQL не может поддерживать большое число параллельных пользователей потому, что он испытывает недостаток блокировки уровня строки. Это может быть истинно для некоторых специфических прикладных программ, но не в общем случае. Как всегда, все зависит полностью от того, что прикладная программа делает, и каков образец доступа/модификации данных.

Плюсы блокировки строки:

Меньшее количество блокировок находятся в противоречии при вызове различными строками во многих потоках.
Нужно меньшее количество изменений для обратных перемоток.
Делает возможным блокировать одиночную строку длительное время.

Минусы блокировки строки:

Берет большее количество памяти, чем блокировки уровня страницы или таблицы.
Работает медленнее, чем блокировки уровня страницы или таблицы, когда используется одна большая часть таблицы потому, что в данном случае нужно делать намного больше блокировок.
Определенно намного хуже, чем другие блокировки, если Вы часто делаете GROUP BY на большой части данных, или если требуется часто просматривать целую таблицу.
С более высоким уровнем блокировки можно также легко поддерживать блокировки различных типов, чтобы настраивать прикладную программу.

Блокировки таблицы превосходят блокировки уровня страницы или отдельной строки в следующих случаях:

Обычное чтение.
Чтение и модификации на строгих ключах. Это тот случай, где один поток модифицирует или удаляет строку, которая может быть выбрана чтением ключа:
```
UPDATE table_name SET column=value WHERE unique_key#
DELETE FROM table_name WHERE unique_key=#
```
SELECT объединенный с INSERT (иногда с UPDATE и DELETE).
Много просмотров или GROUP BY на целой таблице без записи.

Другие параметры для блокировки уровня страницы/строки:

Versioning (подобно тому, что мы используем в MySQL для параллельных вставок), где Вы можете иметь одну запись в то же самое время, когда идет много чтений. Это означает, что база данных или таблица поддерживает различные представления данных в зависимости от того, когда процесс к ним обратился. Также известно под названиями "копии по запросу" или "копии на запись".

Копия по запросу во многих случаях намного лучше, чем блокировка уровня строки или страниц. Самый плохой случай, однако, использует намного больше оперативной памяти, чем при использовании нормальных блокировок.

Вместо того, чтобы использовать блокировку уровня строки, можно применить блокировки уровня прикладной программы. (Подобно get_lock/release_lock в MySQL). Это работает, конечно, только в хороших прикладных программах.

Имеются некоторые советы относительно блокировки:

На прикладной программе для web почти все клиенты делают большое количество выборов, очень немногие удаляют данные, модификации идут главным образом на ключах и вставках в некоторых специфических таблицах. Ядро MySQL ОЧЕНЬ хорошо настроено для этого.

Параллельные пользователи не проблема, если каждый из них не смешивает модификации и выборы, которые должны исследовать много строк в одной таблице.

Если смешиваются вставки и удаления на той же самой таблице, то INSERT DELAYED может сильно помочь.

Можно также использовать LOCK TABLES, чтобы ускорить дела (много модификаций внутри одиночной блокировки выполняются намного быстрее, чем модификации без блокировок). Разделение данных к различным таблицам также будет весьма полезно.

Если Вы получаете проблемы быстродействия с блокировками таблицы в MySQL, Вы можете решить их, если преобразовать некоторых из Ваших таблиц к типу BDB. Подробности в разделе "7.5 Таблицы BDB или Berkeley_DB".

Раздел оптимизации в данном руководстве охватывает много различных аспектов того, как правильно настроить прикладную программу. Подробности в разделе "5.2.11 Другие советы по оптимизации".

6.5 Комментарии относительно потоков RTS

Я пробовал использовать пакет потоков RTS с MySQL, но застрял на следующих проблемах:

Они используют старую версию POSIX calls, и очень утомительно делать обертки для всех функций. Я склонен думать, что было бы проще изменить библиотеки на самую новую POSIX-спецификацию.

Некоторые обертки уже написаны. Подробности в файле mysys/my_pthread.c.

По крайней мере следующее должно быть изменено:

pthread_get_specific должен использовать один параметр. sigwait должен брать два параметра. Много функций (по крайней мере pthread_cond_wait, pthread_cond_timedwait) должны возвратить код ошибки. Сейчас они возвращают -1 и устанавливают errno.

Другая проблема: потоки уровня пользователя используют сигнал ALRM, а это прерывает много функций (read, write, open...). MySQL должен делать повторение на прерывании, но попробуй-ка их все отследи!

Самая большая нерешенная проблема:

Чтобы получать тревоги уровня потока, я изменил mysys/thr_alarm.c, чтобы ждать между тревогами с помощью pthread_cond_timedwait(), но это прерывается с ошибкой EINTR. Я пробовал отлаживать библиотеки потоков относительно того, почему это случается, но не смог найти простое решение.

Если кто-то хочет попробовать собрать MySQL с потоками RTS, я предлагаю:

Измените использование функций MySQL с библиотеки потоков на POSIX. Это довольно просто.
Компилируйте все библиотеки с -DHAVE_rts_threads.
Компилируйте thr_alarm.
Если имеются некоторые маленькие различия в реализации, они могут быть исправлены, заменяя my_pthread.h и my_pthread.c.

Запустите thr_alarm. Если это выполняется без сообщений ``warning'', ``error'' и им подобных, Вы на правильном пути. Даже имеется одно успешное выполнение на Solaris:

Main thread: 1
Thread 0 (5) started
Thread: 5  Waiting
process_alarm
Thread 1 (6) started
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 1 (1) sec
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 2 (2) sec
Thread: 6  Simulation of no alarm needed
Thread: 6  Slept for 0 (3) sec
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 4 (4) sec
Thread: 6  Waiting
process_alarm
thread_alarm
Thread: 5  Slept for 10 (10) sec
Thread: 5  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 5 (5) sec
Thread: 6  Waiting
process_alarm
process_alarm
...
thread_alarm
Thread: 5  Slept for 0 (1) sec
end

6.6 Отличия между разными пакетами потоков

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

Имеются по крайней мере три типа пакетов потоков:

Пользовательские потоки в одиночном процессе. Переключение управляется сигналами, и библиотека управляет всеми функциями non-thread-safe с блокировками. Операции Read, write и select обычно управляются со специфическим для потока выбором, который переключается на другой поток, если текущий ждет данные. Если пакеты уровня пользователя интегрированы в стандартные библиотеки (FreeBSD и BSDI), пакет потоков проще, чем те пакеты, которые должны отобразить все опасные обращения (MIT-pthreads, FSU Pthreads и RTS threads). В некоторых средах (например, SCO), все системные вызовы поточно-безопасны, так что отображение может быть выполнено очень легко (FSU Pthreads на SCO). Нижняя сторона: все отображенные обращения берут небольшое время, и очень сложно обработать все ситуации. Имеются обычно и некоторые системные вызовы, которые не обработаны пакетом потоков (всемирно известное сочетание MIT-pthreads с сокетами). Планирование потоков также оптимально не всегда.
Потоки уровня пользователя в отдельных процессах. Переключение выполнено ядром, и все данные разделены между потоками. Пакет управляет стандартными обращениями, чтобы позволить совместно использовать данные между потоками. LinuxThreads использует этот метод. Нижняя сторона: большое количество процессов. Потоки создаются медленно. Если один поток рушится, остальные обычно остаются в памяти, приводя к зависанию, и Вы должны уничтожить их всех перед перезапуском. Переключение несколько затруднено.
Потоки на уровне ядра (они же ядерные потоки). Переключение обработано библиотекой потоков или ядром и работает очень быстро. Все выполнено в одном процессе, но на некоторых системах команда ps может показывать различные потоки. Если один поток аварийно завершен, то накроется весь процесс. Большинство системных вызовов безопасны с точки зрения потоков. Solaris, HP-UX, AIX и OSF1 имеют ядерные потоки.

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру