Какой враг для сисадмина — самый страшный? Думаете, ничего хуже пользователя уже не придумаешь? Или, может быть, главный враг — это начальник?
Работа системного администратора уникальна в своем роде. Трудно найти профессию, в которой специалиста так часто не понимают сослуживцы и собственное начальство. Повару не приходится доказывать, что ему для работы нужны соль и сахар. Никто не спорит с инженером, что трехэтажный дом нельзя строить без лестницы. Главврача не нужно убеждать, что пациентов не должны лечить практиканты. Только сисадмину постоянно приходится отстаивать банальные истины. Самый страшный его враг — некомпетентность.
Некомпетентные пользователи — это еще не так обидно. В самом деле, менеджерам приходится порой иметь дело с куда более бестолковыми клиентами. В конце концов, для поддержки пользователей можно завести отдельного специалиста. Правда, тут кроется один нюанс, особенно если речь идет о небольшой фирме.
Вряд ли какому-нибудь клиенту придет в голову попросить автомеханика после починки машины пару часиков бесплатно поработать водителем. А вот сисадмина часто просят поработать вместо себя на компьютере. «Ну ты же компьютерщик! Помоги нам оформить презентацию (сделать таблицу в Excel, нарисовать вывеску, записать компакт-диск, начертить план этажа в Autocad и разработать тремерную модель планеты в натуральную величину)». Первые два года работы начинающий сисадмин, жаждущий быть полезным, бросается помогать всем и каждому. Потом, оглядевшись вокруг, чешет репу и внезапно понимает, что делает работу, за которую получает зарплату кто-то другой. В самом деле, рисование всех этих таблиц и презентаций по разным областям деятельности фирмы — прямая обязанность соответствующих специалистов. Причем похвалу каждый из них оставит себе, а в случае неудачи — не преминет свалить ее на сисадмина.
Системный администратор не должен выполнять чужую работу. Каждый сотрудник должен сам уметь делать презентации, включать проектор, печатать на принтере, работать в текстовых редакторах и электронных таблицах. В идеале. Как быть, если пользователи продолжают доставать своими просьбами?
Нужно учиться говорить «нет» каждый раз, когда это позволяет ситуация. А позволяет она это почти всегда. Если соблюдать некоторые правила.
Правило первое. «Нет» нужно говорить всегда
Во-первых, обозначить свое место и свои обязанности на новом месте работы нужно с самого начала. Если пользователи привыкнут к тому, что сисадмин готов выполнить любые их просьбы, даже самые нелепые, отучить их будет ох, как трудно. Причем на имидже сисадмина это скажется просто губительно: все будут считать, что он вконец обленился. Иногда проще сменить место работы, чем собственную репутацию и список обязанностей.
Во-вторых, нужно быть последовательным. Если сисадмин отказывает Вере Петровне, сутулой очкастой даме бальзаковского возраста, но с удовольствием помогает симпатичной юной Леночке из того же отдела, уважения ему это не добавит. Перед сисадмином все пользователи должны быть равны, за исключением разве что высокого начальства.
В-третьих, если в конторе несколько админов, они должны вести себя одинаково. Офис — не прокуратура, политика «добрый и злой следователь» здесь выглядит, по меньшей мере, странно. «Злой» сисадмин будет иметь крайне непривлекательную репутацию, а «доброго» просто замучают пользователи.
Правило второе. Людей нужно обучать
Не нужно выполнять за пользователя действия, с которыми может справиться любой мало-мальски сообразительный человек. Его нужно просто научить.
Допустим, пришел сотрудник и просит подключить ему сетевой принтер. Сотрудник вряд ли чему-то научится, если сисадмин тут же побежит на рабочее место, подключит принтер, мельком бросив: «Смотри, как надо».
Правильнее спросить у человека: «В чем проблема? Что конкретно у вас не получается?». Если сотрудник никогда раньше не делал ничего подобного, придётся показать ему последовательность действий и попросить повторить эти действия на своем рабочем месте. Возможно, в процессе подключения человек пару раз переспросит, какую и где нажать кнопку. Зато с высокой долей вероятности в следующий раз он не будет требовать личного участия сисадмина, а просто позвонит, чтобы спросить: «Как называется наш новый принтер?».
Исключение, на самом деле, нужно делать только в одном случае — если от сроков решения данной проблемы напрямую зависит прибыль предприятия. Иначе руководство бездействия не простит и будет право.
Правило третье. Нужно уметь объяснять, почему «нет»
Нет ничего глупее, чем просто сказать «нет» или «я не буду этого делать». Пользователь тоже человек, и его нужно уважать. Ему надо объяснить, почему сисадмин не будет выполнять за него работу. Приходит, к примеру, сотрудник и просит:
- Помогите мне сделать презентацию.
- Какие у вас проблемы?
- Я не умею.
- Хорошо, а вы мне помогите настроить сервер.
- С какой это стати?
- А я не умею. Хотел бы научиться, да все время занят презентациями.
Однако при этом пользователю не нужно давать понять, что его проблема сисадмина абсолютно не интересует. Иначе сисадмина все будут представлять как исключительно злобного субъекта, который потирает ручки и ехидно ухмыляется: «Ни черта у тебя не получится!». Нормальный сисадмин заинтересован в том, чтобы проблема пользователя решилась, но времени при этом должно быть потрачено как можно меньше. А поэтому он всегда должен иметь под рукой запасной вариант решения проблемы.
Правило четвертое. Нужно иметь запасной вариант
Как быть, если сотрудник — ценный специалист в своей узкой области, но с компьютерами общается с трудом, в силу возраста, гуманитарного образования или других причин? А если таких сотрудников десять? А если сто? Нормальная практика — приставить к таким специалистам помощников из молодых сотрудников того же отдела, тех, кто хорошо владеет компьютером и легко обучается.
Для выполнения простых систематических действий стоит написать небольшие инструкции. Памятка должна быть краткой (желательно, чтобы она умещалась на одном листе), содержать последовательность действий с указанием способа решения одной конкретной проблемы и написана, по возможности, простыми, понятными словами. Никто не будет изучать талмуд на тему «Как подключать сетевые принтеры, плоттеры, заправлять бумагу, менять картридж и пользоваться ксероксом». Достаточно повесить возле плоттера краткие памятки: «Как заправить бумагу» и «Как подключиться к этому сетевому плоттеру».
Кроме всего прочего, в небольшой конторе, где не все сотрудники имеют возможность помогать друг другу и нет отдельной службы поддержки, можно закупить партию книжек «Excel для чайников», «PowerPoint для чайников» и т.п. и вручать их особо некомпетентным.
Если вводится новое программное или техническое средство, куплено новое многофункциональное печатающее устройство, установлена новая версия серверного ПО и т.п., имеет смысл собрать всех сотрудников сразу или по отделам и устроить презентацию. Еще лучше — дать сотрудникам некоторое время попользоваться нововведением, а затем собрать их вместе и ответить на вопросы.
Правило пятое. Нужно фиксировать заявки пользователей
Хорошее правило — требовать от пользователей излагать свои просьбы письменно. Сразу по нескольким причинам.
Во-первых, перед тем как писать заявку, человек лучше подумает и изложит ее в более понятном и удобоваримом виде. Возможно, он даже передумает ее писать, потому что догадается, как это можно сделать самому, или же постесняется заявлять о собственной некомпетентности.
Во-вторых, в случае возникновения конфликтов и жалоб пользователей вышестоящему начальству, крайне полезно, чтобы история конфликта была подтверждена документально. Иначе разобраться ни в одной проблеме будет просто невозможно, вся беседа будет сведена к «он первый начал», как в детской песочнице.
В-третьих, заявки, собранные в одном месте, можно использовать в качестве органайзера, чтобы никого не забыть и выделить наиболее важные проблемы. И, наконец, у сисадмина будет всегда под рукой наглядная статистика по выполненной работе.
Идеальный вариант для сбора заявок — не толстая тетрадка, и даже не электронная таблица, а небольшой сайт. Его даже не нужно делать самому — можно найти готовый скрипт или, на худой конец, использовать форум. Тогда пользователь легко сможет внести заявку со своего рабочего места и увидеть результат ее выполнения.
При этом нужно соблюсти три условия. Во-первых, желательно использование системы заявок зафиксировать в приказе за подписью директора, где было бы четко сказано, что выполняются только заявки, размещенные на сайте. Во-вторых, опять-таки, нужно быть последовательным и во всех случаях требовать письменной заявки, иначе такой сайт быстро заглохнет. В-третьих, пользователь должен видеть отклик на свою заявку как можно быстрее. Он должен знать, что его просьба прочтена и будет выполнена.
Правило шестое. Нужно заручиться поддержкой начальства
Все вышестоящие правила не имеют никакого значения, если сисадмина не поддерживает руководство. Все действия нужно обсудить с непосредственным начальником и заручиться его поддержкой. Начальник не должен отдавать распоряжения, противоречащие общим правилам. Но как быть, если начальник тоже не очень-то компетентен, что встречается не так уж и редко?
Иногда приходится выполнять и чужую работу, особенно, если возникшая проблема не имеет явных признаков неисправности, сбоев оборудования, неверных настроек. Это реальная история, связанная с поиском и устранением причин низкой производительности сетевого приложения на примере 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". Результат будет отображен в информационном окне программы.
В режиме тестирования можно получить статистику по скорости считывания и числу блоков, читаемых с задержкой. При наличии медленно считываемых секторов, можно определить их принадлежность конкретному файлу. Для этих целей можно воспользоваться консольной утилитой 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С, в которой открыта эта база. Утилита позволяет отобразить общее число таблиц в базе данных, просматривать их список, состав и содержимое полей, получить перечень, размер и уровень заполнения отдельных файлов, а в файлах таблиц получить список индексов и процент их использования.
Теперь настройка, отредактируйте конфиг файл /etc/samba/smb.conf что бы он выглядел примерно так
; Глобальные настройки сервера
[global]
; General server settings
; Имя компа, как будет видно в сетевом окружении
netbios name = main-server
server string =
; Рабочая группа клиентов
workgroup = WORKGROUP
announce version = 5.0
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
passdb backend = tdbsam
security = user
null passwords = true
; Файл для альясов имен юзеров
username map = /etc/samba/smbusers
name resolve order = hosts wins bcast
wins support = yes
; Поддержка принтеров
printing = CUPS
printcap name = CUPS
; Логи
log file = /var/log/samba/log.%m
syslog = 0
syslog only = no
; Настройка привязки к интерфейсам, на каких слушать, если не указано слушает на все интерфейсах
; interfaces = lo, eth0
; bind interfaces only = true
;
;[print$]
; path = /var/lib/samba/printers
; browseable = yes
; guest ok = yes
; read only = yes
; write list = root
; create mask = 0664
; directory mask = 0775
;
;[printers]
; path = /tmp
; printable = yes
; guest ok = yes
; browseable = no
;
;[DVD-ROM Drive]
;path = /media/cdrom
;browseable = yes
;read only = yes
;guest ok = yes
; Шара жесткого диска
; Имя шары, видно у клиентов
[SDA1-250GB]
; Путь к расшариваемому диску
path = /media/sda1
; Можно ли просматривать
browseable = yes
read only = no
guest ok = no
create mask = 0644
directory mask = 0755
; Привязка к определенному имени пользователя или группе, имена через пробел
; force user = user1 user2
; force group = group1 group2
; Еще один жесткий диск, по аналогии с тем что выше
[SDE1-120GB]
path = /media/sde1
browseable = yes
read only = no
guest ok = no
create mask = 0644
directory mask = 0755
Теперь надо разобраться с пользователями, Samba использует пользователей которые уже есть в системе, возьмем для примера имя user, допустим что он уже есть в системе, надо внести его в базу данных SMB и назначить пароль для доступа к расшаренным ресурсам, сделаем это командой
smbpasswd -a user
Вам будет предложено ввести пароль, пользователь будет добавлен в базу, теперь необходимо включить этого пользователя.
smbpasswd -e user
Далее создадим альяс для имени пользователя user что бы облегчить себе доступ с Windows машины на которой у нас например пользователь с именем Admin, для этого создадим и отредактируем файл /etc/samba/smbusers
touch /etc/samba/smbusers
vim /etc/samba/smbusers
Впишите в файл пару строк
# Unix_name = SMB_name1 SMB_name2
user = Admin
На этом настройка закончена, перезапустите Samba командой /etc/init.d/samba restart и можно пользоваться расшаренными ресурсами.
Удачной вам настройки.