Методика поиска причин низкого быстродействия сетевых приложений


    Будни системного администратора. Иногда приходится выполнять и чужую работу, особенно, если возникшая проблема не имеет явных признаков неисправности, сбоев оборудования, неверных настроек. Это реальная история, связанная с поиском и устранением причин низкой производительности сетевого приложения на примере 1С Предприятия версии 8.0 -8.2 с файловой базой данных.

    С продукцией 1С я знаком довольно поверхностно, но, тем не менее, пришлось заниматься решением данной проблемы в рамках существующего договора в одной из обслуживаемых организаций. Сама проблема заключалась в том, что после перехода на версию 8.x, расчет, например, оборотно-сальдовой ведомости при работе с сетевой файловой базой данных стал выполняться очень медленно. Если база данных использовалась в локальном варианте, расчет выполнялся за несколько секунд, в сетевом - иногда и несколько часов. Реакция на простейшие действия пользователей рабочих мест программного комплекса 1С могла составлять минуты и часто воспринималась ими как зависание программы. Нередко для продолжения работы на рабочих местах выполнялось принудительное завершение программы с использованием диспетчера задач, или вообще - нажатием кнопки сброса, что вполне ожидаемо, могло привести (и нередко приводило) к разрушению базы данных. Рекомендации специалистов, сопровождающих комплекс 1С , сводились к необходимости модернизации оборудования, увеличению пропускной способности сетевых устройств и в конечном итоге, переходу на SQL-версию базы данных и гигабитную сеть, что влекло за собой значительные финансовые расходы. Естественно, подобные расходы должны быть обоснованы реальной необходимостью, и подтверждены фактическими данными на основе анализа причин невозможности нормальной работы программного комплекса 1С на существующей конфигурации оборудования и используемого программного обеспечения.

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

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





Оценка пропускной способности локальной сети.

    Начну с того, что рекомендация по переводу сети со 100-мегабитного оборудования на 1 - гигабитное (1000 Мбит/сек) никак не может быть решением проблемы. Такой переход не может увеличить реальную скорость передачи данных в 10 раз, поскольку, данные в локальной сети Ethernet передаются не непрерывно, а блоками, размер которых определяется значением параметра MTU (Maximum Transmission Unit ) сетевого адаптера. Проще говоря, размером внутренней буферной памяти сетевой карты, которая используется для приема и передачи кадров Ethernet. Стандартно размер передаваемого кадра равен 1500 байт (MTU=1500), т.е обмен между 2-мя сетевыми адаптерами выполняется блоками, максимальный размер которых не превышает 1500 байт. Очевидно, чтобы сформировать кадр для передачи, нужно выполнить как минимум несколько подпрограмм на уровне пользовательского приложения и драйверов, обеспечивающих формирование данных, подготовку аппаратной части к передаче, собственно передачу и контроль результатов. Плюс к этому можно добавить обработку асинхронных прерываний, отложенных процедур, диспетчеризацию процессов и т.п. Таким образом, для того, чтобы осуществить передачу 1500 байт процессор должен выполнить довольно внушительное количество команд, которое может составлять десятки и даже сотни тысяч. При тактовой частоте работы CPU, например, в 3 гигагерца, выполнение такого количества команд в любом случае займет больший промежуток времени, чем передача 1500 байт на частоте 1 гигагерц. Поэтому, даже теоретически, перевод сети на скорость передачи в 1 гигабит не может увеличить на порядок ( а тем более - на несколько порядков) скорость работы с сетевой файловой базой данных.

    Наиболее простым способом проверки реальной скорости передачи данных между узлами локальной сети можно считать простое копирование файлов. Однако, для детального анализа ситуации желательно все же разделить процессы, связанные с файловыми операциями при копировании и с передачей данных в локальной сети. Наиболее популярными программными средствами проверки пропускной способности сетевых соединений являются утилиты NTttcp от Microsoft, iperf с открытым кодом, и NetCPS от NetChain. Принцип работы всех этих утилит основан на обмене данными между двумя запущенными экземплярами программы, работающими либо в режиме отправителя (sender), либо в режиме получателя (receiver) данных по протоколу TCP. Т.е один экземпляр программы запускается в режиме сервера, слушающего определенный TCP-порт, а второй - в режиме клиента, выполняющего передачу данных на этот сервер. На мой взгляд, самой простой и удобной из перечисленных программ, является утилита командной строки NetCps, Скачать .zip ~ 23кб . Архив содержит исполняемый модуль netcps.exe, текстовый файл readme.txt с кратким описанием на английском языке, и файл с исходным текстом на языке C++. Установка не требуется. Подсказку по использованию netcps.exe можно получить при запуске программы без параметров или с ключом -help. Формат командной строки:

netcps.exe [ параметры ] [ удаленный узел]

Ключи командной строки:

-Pn - номер порта, используемый программой. Если параметр не задан, то будет использован порт TCP 4455
-server - программа будет выполняться в режиме сервера. Если параметр не задан - то в режиме клиента.
-mn - количество мегабайт даттых для передачи от клиента к серверу. Если не задано, то используется значение 100.

Примеры использования:

netcps -server - запустить программу в режиме сервера. После старта на экран будет выдано сообщение Waiting for new connection и программа перейдет в режим ожидания входящих соединений. Для завершения работы можно воспользоваться комбинацией клавиш CTRL+C или CTRL+Break
netcps 192.168.1.1 - запустить программу в режиме клиента для передачи данных на сервер с IP-адресом 192.168.1.1
netcps COMPUTER - запустить программу в режиме клиента для передачи данных на сервер COMPUTER
netcps computer -m1000 запустить программу для передачи 1000 мегабайт данных на сервер computer
Для записи результатов работы в текстовый файл можно воспользоваться перенаправлением вывода:

NetCPS.exe comp0 -m1000 > comp0.txt - результаты передачи данных будут записаны в файл comp0.txt текущего каталога.

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

В процессе обмена данными между клиентом и сервером отображается скорость передачи, представленная в байтах в секунду (CPS), килобайтах в секунду (KPS) и мегабайтах в секунду (MPS). Пример протокола обмена данными:

NetCPS 1.0 - Entering client mode. Press ^C to quit
Connecting to 192.168.0.130 port 4455... Connected!
---> CPS 11503616.00 KPS: 11234.00 MPS: 10.97
---> CPS 11538432.00 KPS: 11268.00 MPS: 11.00
---> CPS 11583488.00 KPS: 11312.00 MPS: 11.05
---> CPS 11571200.00 KPS: 11300.00 MPS: 11.04
---> CPS 11534336.00 KPS: 11264.00 MPS: 11.00
. . .
Avrg CPS 10548311.00 KPS: 10301.08 MPS: 10.06
Peek CPS 11594752.00 KPS: 11323.00 MPS: 11.06
Done. 1048576000 Kb transferred in 99.41 seconds.

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

Avrg - средняя скорость передачи данных.
Peek - максимальная скорость передачи
Done - объем переданных данных в килобайтах и время передачи в секундах.

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





Оценка производительности оборудования файлового сервера и рабочих станций.

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

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

В качестве одного из средств для проверки быстродействия дисковой системы можно использовать программу тестирования дисков Victoria для DOS и (или) Windows. В целом, для решения данной задачи вполне достаточно версии под Windows - простой и удобной в использовании.     По сравнению с DOS-версией, Victoria For Windows обладает более скромными возможностями по настройке накопителя и выбору режимов тестирования, и на данный момент не имеет поддержки русского языка , однако ей проще пользоваться и имеющихся возможностей вполне достаточно для оценки технического состояния дисковых устройств на основе содержимого таблицы SMART и оценки их быстродействия с возможностью работы через собственный драйвер или Windows API .

Программа не требует установки, просто скачайте ее по ссылке на странице загрузки сайта автора,

Для анализа состояния SMART-атрибутов выбираем режим работы через программный интерфейс Windows - включаем кнопку API в правой верхней части основного окна. Затем выбираем нужный накопитель - нажимаем на кнопку Standard в основном меню программы и подсвечиваем мышкой нужный накопитель в окне со списком жестких дисков. В информационном окне будет отображен паспорт накопителя - модель, версию аппаратной прошивки, серийный номер, размер и т.п. Для получения данных SMART выбираем пункт меню SMART и жмем кнопку "Get SMART". Результат будет отображен в информационном окне программы.



Victoria for Windows


В режиме тестирования можно получить статистику по скорости считывания и числу блоков, читаемых с задержкой. При наличии медленно считываемых секторов, можно определить их принадлежность конкретному файлу. Для этих целей можно воспользоваться консольной утилитой NFI.EXE (NTFS File Sector Information Utility) из состава пакета Support Tools от Microsoft. Скачать 10кб
Формат командной строки
nfi.exe drive-letter [logical-sector-number]
drive-letter - буква диска. Можно задавать без двоеточия.
logical-sector-number - номер сектора относительно начала логического диска, задаваемого значением drive-letter Номер сектора может задаваться как в десятичном, так и в шестнадцатеричном виде (1000 - десятичное значение, 0x1000 - шестнадцатеричное). Если, например, логический диск C: начинается с физического блока с номером 63, то в качестве номера логического сектора нужно указывать номер физического плюс 63.

nfi.exe C: 65234 - определить имя файла, которому принадлежит логический сектор 65234
nfi.exe C: 0xBF5E34 - то же самое, но номер сектора задан в шестнадцатеричной системе счисления
В результате выполнения команды будет выдано сообщение

***Logical sector 12541492 (0xbf5e34) on drive C is in file number 49502.
C:\myfile.dat


Т.е. интересующий нас медленно читаемый сектор принадлежит файлу C:\myfile.dat

Утилита NFI позволяет получить список логических секторов, которые отведены для размещения конкретного файла:

nfi.exe nfi "H:\BASE\1Cv8.1CD" - отобразить список логических секторов, которые принадлежат файлу H:\BASE\1Cv8.1CD

Зная диапазон номеров логических секторов, можно пересчитать их в физические номера блоков LBA для Victoria и выполнить многократное выполнение теста для определения наличия считывания с повышенной задержкой. Такое тестирование лучше проводить в среде DOS (Victoria for DOS) чтобы исключить задержки вызываемые выполнением других процессов в мультизадачной среде Windows.


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

Некоторые примеры использования утилит Sysinternals Suite:

Для оценки степени фрагментации отдельных файлов и, при необходимости, их дефрагментации, используется утилита Contig

Contig.exe -a C:\BASE\*.* - провести анализ на фрагментированность всех файлов в каталоге C:\BASE\

Contig.exe C:\BASE\*.* - выполнить дефрагментацию всех файлов в каталоге C:\BASE.

Contig.exe -a -s C:\windows\*.exe - выполнить анализ всех файлов с расширением .exe в каталоге C:\Windows и его подкаталогах (ключ -s)

Contig.exe C:\windows\system32\*.exe - дефрагментировать все файлы с расширением .exe в системном каталоге C:\Windows\System32

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

pagedefrag -e -t 10 - выполнять дефрагментацию при каждой загрузке и установить режим ожидания 10 секунд для отмены выполнения при нажатии пользователем любой клавиши.

pagedefrag -o - выполнить однократную дефрагментацию при следующей перезагрузке системы.

pagedefrag -n - отменить ранее запланированную дефрагментацию.

Для оценки загруженности системы и получения информации о выполняющихся процессах можно использовать утилиты Process Monitor (Procmon) и Process Explorer (Procexp)

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

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

    Несколько слов о том, что такое база данных. Без стандартных определений, найти которые, при необходимости, не составит особого труда. Смысл использования любой базы данных заключается в том, чтобы получить возможность упорядоченного поиска информации по определенным признакам. Базы данных, в подавляющем большинстве случаев имеют табличную структуру (реляционные базы данных), где каждый элемент таблицы (запись) состоит из определенного набора полей, в которых могут содержаться как пользовательские данные, так и дополнительная информация для связи между таблицами и организации упорядоченного поиска в базе. Такие поля называются ключевыми полями или просто ключами. В качестве примера реализации базы данных может служить обыкновенная книга. Для поиска нужной информации в книге можно просто перечитать подряд все страницы, но можно с помощью оглавления найти, например, раздел, где могут находиться искомые данные и (или) номер соответствующей страницы, т.е, если известен номер страницы, (используемый в качестве ключа), время поиска информации значительно сокращается. Но в отличии от страниц в книге, записи в базе данных располагаются в том порядке, в каком заносятся пользователем. Это называется физическим порядком следования записей (по аналогии - это книга, в которой страницы пронумерованы, но расположены не по порядку, а как получится). Обработка информации, содержащейся в базе практически всегда требует представление записей не в физическом, а в другом, оптимальном для поиска нужной информации, представлении, поэтому, одними из основных требований, предъявляемым к системам управления базами данных (СУБД), являются возможность представления данных в определенном, отличном от физического, порядке. Эффективным средством решения этих задач является использование индексов. Индекс - это таблица, которая содержит ключевые значения для каждой записи в других таблицах, содержащих данные, и записанные в порядке, необходимом для пользователя. Правильно построенный индекс позволяет быстро получить искомую информацию, не зависимо от физического расположения записи в таблице. И наоборот, отсутствие индекса или его неоптимальное построение может приводить к резкому снижению производительности приложений, работающих с базой данных.

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

В любом случае, возможность воспроизвести ситуацию плюс уверенность в том, что причина медленной работы не имеет отношения к оборудованию, операционным системам и прочим особенностям локальной сети, позволила выдвинуть предположение, что узкое место - это индекс (ы), которые не соответствуют физическому состоянию базы. Со слов представителя 1С, индексы перестраиваются и актуальны на данный момент времени. Но, после того, как были отработаны "рекомендации по увеличению быстродействия", доверия к подобным заявлениям уже не было. К сожалению, на тот момент времени, найти какое-либо описание структуры БД, особенно перечень и назначение индексов, а также утилиты для ее обслуживания не удалось, и действовать пришлось методом "научного тыка" - искать в меню программы любые кнопки, которые бы были связаны с обновлением индексов. В конце концов, выяснилось, что для нормальной работы 1C нужно было обновить индекс полнотекстового поиска через меню "Операции" - "Управление полнотекстовым поиском" - "Обновить индекс" После выполнения данной операции быстродействие при работе с файловой базой увеличивается в десятки раз. И в заключение, личное предположение - очевидно, в БД 1С присутствуют индексы, которые не обновляются представителями тех. поддержки 1С, с использованием стандартных процедур тестирования и восстановления.

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

Уже после завершения работы по определению причин низкого быстродействия удалось найти очень бы пригодившуюся утилиту для просмотра содержимого баз данных .1CD на сайте pro1c.org.ua Для работы с базой, программа tool_1CD.exe не требует установленной 1С. Соответственно и не нужны никакие пароли для открытия файла. Файл базы открывается монопольно, поэтому нельзя просматривать базу при запущенной 1С, в которой открыта эта база. Утилита позволяет отобразить общее число таблиц в базе данных, просматривать их список, состав и содержимое полей, получить перечень, размер и уровень заполнения отдельных файлов, а в файлах таблиц получить список индексов и процент их использования.

Утилита для просмотра базы 1С



Если вы желаете поделиться ссылкой на эту страницу в своей социальной сети, пользуйтесь кнопкой "Поделиться"











В начало страницы     |     На главную страницу