Главная страница
Навигация по странице:

  • Структура хранения данных в MySQL

  • Восстановление поврежденных таблиц

  • Удаление и замена ключей

  • Устранение неполадок

  • Количество коннектов в пуле MySQL InnoDB (read/write per sec) MySQL MyISAM

  • Отчет о преддипломной практике


    Скачать 0.64 Mb.
    НазваниеОтчет о преддипломной практике
    Дата21.12.2021
    Размер0.64 Mb.
    Формат файлаdocx
    Имя файлаÄÆùàÆ ÅÄ ÅÉÇèÆêèà é êìöÄÉîÇûêÄììÄî ûàìÆÉà.docx
    ТипОтчет
    #312976
    страница6 из 6
    1   2   3   4   5   6

    4.3 Оптимизация работы MySQL


    MySQL имеет три потенциальных «узких места» при любом подключении. Во-первых, это сетевое соединение клиента с сервером. Во-вторых, это время решения таких задач, как, построение индексов. И наконец, проблема может быть связана с дисковым вводом/выводом. MySQL предоставляет доступ к переменным, с помощью которых ее функционирование можно настроить в соответствии со средой приложения. Все эти переменные можно установить, используя параметр -О в команде mysqld. Например, переменная back_log принимает значение 15 в результате добавления к mysqld параметра -О backjtog=15.

    Ниже следует список полезных переменных:

    bach_log - количество одновременных подключений по TCP/IP в очереди. При наличии большого числа удаленных пользователей, одновременно подключающихся к вашей базе данных, может потребоваться увеличить это число. Отрицательной стороной большого значения является некоторый рост использования памяти и загрузки ЦП.

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

    max Connections - число одновременных соединений, разрешенное сервером баз данных. Если при активной работе пользователи иногда получают отказ в доступе, возможно, это число следует увеличить. Отрицательное последствие - увеличение загрузки сервера, то есть рост использования ЦП, расхода памяти и дискового ввода/вывода.

    table_cache - буфер, используемый для хранения данных, к которым происходит частое обращение. Если выделить под них память, то резко сокращается объем обращений к диску. Отрицательный эффект - существенное увеличение расхода памяти.
    Структура хранения данных в MySQL

    Для хранения каждой таблицы MySQL используется три файла. Например, средних размеров таблица mytable может выглядеть так:

    -rw-rw-- - 1 root root 1034155 Jun 3 17:08 mytable.ISD

    -rw-rw---- 1 root root 50176 Jun 3 17:08 mytable.ISM

    -rw-rw-- - 1 root root 9114 Jun 3 14:24 mytable.frm

    В файле ISD хранятся фактические данные. В файле ISM хранятся данные о ключах и прочие внутренние данные, необходимые MySQL для быстрого поиска данных в файле ISD. Файл f rm содержит структуру самой таблицы.

    Файл ISM наиболее важен для функционирования MySQL. Он настолько важен, что ему посвящена целая утилита isamchk. Запуск isamchk -d выводит сведения о таблице:

    # isamchk -d mytable

    ISAM file: mytable

    Data records: 1973 Deleted blocks: 0

    Recordlength: 343

    Record format: Packed

    table description:

    Key Start Len Index Type

    1 2 50 unique text packed stripped

    Важное поле, которое нужно отметить, это «Deleted blocks» (удаленные блоки). Если его значение слишком велико, то файл понапрасну занимает много лишнего места. Это пространство можно освободить. В результате выполнения следующей команды таблица будет просмотрена и создана заново, при этом будут в большинстве своем устранены ошибки и высвобождено свободное пространство: isamchk -r mytable. Еще большего увеличения скорости можно добиться, применив к таблице команду Isamchk -а. Эта команда анализирует размещение данных в таблице. Ее следует выполнить после вставки или удаления большого числа записей.
    Восстановление поврежденных таблиц

    При авариях сервера или по другим естественным причинам таблица базы данных может оказаться поврежденной. С помощью isamchk обеспечивается несколько уровней восстановления:

    isamchk mytable – команда исправляет большинство обычных ошибок в таблице. Добавление параметров -г и -v приводит к выводу дополнительных сведений о том, что было нарушено.

    isamchk -rq mytable – команда осуществляет быструю проверку и при необходимости исправление только файла ISM, файл ISD при этом не проверяется.

    isamchk -e mytable – с данным параметром производится полная проверка и исправление всего, что можно, и устранение любых повреждений. Такая проверка обычно производится значительно дольше, чем обычная. Выполнение команды прекращается в момент столкновения с первой серьезной ошибкой. Для продолжения проверки даже после нахождения серьезных повреждений передается параметр -v. Тем самым гарантируется отсутствие повреждений в результирующей таблице, но при этом может произойти потеря некоторых данных.
    Удаление и замена ключей

    Иногда ключи замедляют скорость работы с базой данных. Если необходимо ввести большой объем данных, индексирование ключей после каждой вставки может оказаться очень неэффективным. Кроме того, если таблица имеет поврежденные ключи, в результате исправления таблицы утилитой isamchk может произойти потеря данных, связанных с ключом.

    В этих случаях оказывается полезным временное удаление ключей из таблицы и воссоздание их после завершения опасной работы. Следующая команда удаляет ключи из таблицы:

    isamchk -rq -k0

    Если нужно снова вставить ключи, это можно сделать командой:

    isamchk –rq
    Устранение неполадок

    Часто встречавшихся проблем при администрировании MySQL:

    1) Изменения в таблицах доступа не действуют. Нужно выполнять команду mysqladmin reload после внесения изменений в таблицы доступа.

    2) При высокой загрузке MySQL отказывает в подключении.

    1. Сначала необходимо уточнить число соединений, допускаемых сервером. Команда mysqladmin variables покажет его значение в поле max_connec-tions. Можно увеличить это число, запустив mysqld с параметром -О max_connections=###, где ### - предел, который нужно установить.

    2. Можно также проверить значение back_log , которое определяет размер очереди, создаваемой MySQL для входящих соединений, равное 5 по умолчанию. Версии MySQL до 3.22 позволяли увеличить это значение до 64, но в более поздних версиях его можно увеличить до 1024. Однако оно может быть ограничено до 64 операционной системой.

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

    3) MySQL сообщает о невозможности найти файл, который явно существует, или сообщает об ошибках во время его чтения. В большинстве случаев эта проблема связана с числом дескрипторов файлов, о котором говорилось выше. Однако если увеличить буфер таблиц MySQL, ему не потребуется открывать так много файлов, и вы сможете избавиться от этой проблемы. По умолчанию величина буфера таблиц равна 64. Можно увеличить его через значение переменной table_cache .

    4) Число потоков начинает расти, и потоки не завершаются. В некоторых системах с установленным NFS, а также в Linux, есть проблемы с механизмом блокировки файлов. Результатом может быть замораживание потоков. Команда mysqladmin processlist поможет выявить эту проблему. Если в поле «Command» против замороженных потоков стоит «System lock», запустите mysqld с параметром --skip_ locking.

    4.4 Тестирование производительности MySQL


    Для тестирования производительности СУБД была создана небольшая БД (рис. 4.8). Использовавшийся сервер: HP ProLiant DL380 2xXeon3.2, RAM 5 Гб, SCSI HDD u320. Сервер был настроен на максимальную производительность, а приведенные здесь результаты тестов – лучшие из полученных:

    # InnoDB

    sync_binlog                     = 0

    innodb_buffer_pool_size         = 2048M

    innodb_additional_mem_pool_size = 64M

    innodb_log_files_in_group       = 2

    innodb_log_file_size            = 512M

    innodb_log_buffer_size          = 8M

    innodb_flush_log_at_trx_commit  = 0

     

    # MyISAM

    key_buffer              = 1024M

    table_cache             = 1024

    sort_buffer_size        = 16M

    read_buffer_size        = 4M

    read_rnd_buffer_size    = 4M

    myisam_sort_buffer_size = 4M

    query_cache_size        = 16M
    Распределение количества запросов на чтение и запись было выбрано в отношении 80% и 20% соответственно. После запуска на тестирование производилась выдержка в течение нескольких десятков секунд для стабилизации результатов. Было проведено пять тестов, результат усреднялся.

    Тестировались следующие запросы (в процентах от общего числа):

    • чтение из таблицы Friends (95%);

    • чтение Posts и Comments (5%);

    • запись Posts и Comments (95%);

    • создание новых пользователей (Users) и изменение свойств уже существующих (5%).



    Рисунок 4.8 – Схема тестируемой БД

    Оптимизированные алгоритмы работы с БД для MySQL:

    Запрос чтение Friends. Общий вид запроса следующий:

    SELECT user_id, MAX(posts_id)

     FROM posts

     WHERE user_id

     IN (SELECT friend_id

         FROM friends

         WHERE user_id = UserId)

     GROUP BY user_id;
    Для максимально оптимальной выборки необходимо на внутренний запрос подключить индекс по первичному ключу таблицы friends, а для внешнего запроса – первичный ключ по таблице posts.

    Однако, поскольку MySQL всех версий не умеет адекватно оптимизировать внешний запрос вне зависимости от созданных индексов и их явного указания через FORCE(key list), сложный запрос был разбит на два простых: в первом запросе получен список пользователей, а во втором – нужные посты.

    UsersSet = SELECT friend_id FROM friends WHERE user_id = UserId
    и

    SELECT user_id, MAX(post_id) FROM posts WHERE user_id in (UsersSet) GROUP BY user_id
    Чтение Posts и Comments:

    SELECT *

     FROM posts

     WHERE (posts_id = PostId);

     

    SELECT *

     FROM comments

     WHERE ((user_id = UserId) AND (posts_id = PostId))

     ORDER BY comment_date;
    Запись Posts:

    PostID = SELECT MAX(post_id) FROM posts;

    INSERT IGNORE INTO posts (user_id, post_id, post_date, post_title, post_body) VALUES (UserID, PostID, Date, Title, Body);
    Запись Comments:

    SELECT COUNT(*) FROM users WHERE (user_id = iUserId);

    SELECT COUNT(*) FROM users WHERE (user_id = iPosterId);

    SELECT COUNT(*) FROM posts WHERE (post_id = iPostId);

    CommentId = SELECT MAX(comment_id) FROM commnets; INSERT IGNORE INTO \

        comments (user_id, posts_id, comment_id, from_user_id, comment_date, comment_title, comment_body) \

        VALUES (UserId, PostId, CommentId, PosterId, Date, Title, Body);
    Создание пользователя (Users):

    SELECT COUNT(1) FROM users WHERE user_name = UserName;

    INSERT INTO users(user_name) VALUES (UserName);

    GET_LAST_INSERT_ID

    Редактирование свойств пользователя (Users):

    SELECT COUNT(1) FROM users WHERE user_id = UserId;

    UPDATE users SET user_name = UserName WHERE user_id = UserId;
    Таблица 4.1 - Результаты тестирования СУБД MySQL в зависимости от количества подключений

    Количество коннектов в пуле

    MySQL InnoDB

    (read/write per sec)

    MySQL MyISAM

    (read/write per sec)

    1

    600/60

    500/20

    5

    1100/110

    600/50

    10

    1100/110

    600/50

    11-17

    800/70

    400/30

    20 и более

    Отказ от обслуживания

    Отказ от обслуживания

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


    Заключение



    В результате прохождения преддипломной практики в филиале компании “Лукойл-Информ” была изучена структура предприятия, организация работы отдела Автоматизированного управления финансами и персоналом, принципы работы и администрирования программного обеспечения, использующегося в работе отдела.

    При прохождении практики, функциональными обязанностями являлись изучение особенностей работы, установки и конфигурирования программного комплекса 1С:Предпритие. Для выполнения поставленных задач были изучены, как нормативные материалы, так и специализированная литература, Интернет-источники, предоставляющие информацию по данной тематике.

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

    Изученные вопросы являются актуальными при установке и настройке автоматизированных систем учета, а анализ современных СУБД и изучение особенностей их работы позволили получить практические навыки для разработки программного обеспечения в рамках будущего дипломного проекта.

    Список используемых источников





    1. Дейт К. Введение в системы баз данных: Пер. с англ.- К.; M.; СПб: Изд. Дом "Вильямс", 2004. - 848с.

    2. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика. М: Издат. дом "Вильямс", 2004. -1120с.

    3. Королев М.А. и др. Теория экономических информационных систем. - М.: Финансы и статистика, 2002. - 223 с.

    4. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем, 2002.

    5. Сайт разработчиков операционной системы семейства Windows, http://www.microsoft.com

    6. Сайт разработчиков системы управления базы данных MySQL, http://www.mysql.com

    7. Сайт разработчиков системы управления базы данных PostgreSQL, http://www.postgresql.com

    8. Сайт фирмы 1С, http://v8.1c.ru/buhv8/

    9. Справочное руководство по MySQL, http://www.mysql.ru/docs/man/MySQL_indexes.html

    10. Сравнение MySQL и PostgreSQL с точки зрения разработчика, http://aztips.blogspot.com/2008/10/mysql-postgresql.html
    1   2   3   4   5   6


    написать администратору сайта