Дело в том, что Кронос все свои операции по работе с файлами данных сопровождает блокировками (lock) с отрицательными смещениями и блокировками области 0-4 в файлах *.tad, И только по ним определяет, работает ли еще кто-то с Кроносом, с данными, проводит ли коррекции, и т.д.
Суть проблемы состояла в том, что в ДОС-клиенте есть понятие блокировки фрагмента файла, но нет различия между блокировками на запись и на чтение, как в любой нормальной ОС. (Надеюсь понятно, о чем речь? - На чтение лок могут ставить все, не мешая друг другу на один кусок, но никто при этом не сможет поставить лок на запись. На запись же наоборот, если стоит лок на запись, то вообще никто никаких локов больше поставить не может на пересекающийся с заблокированным сегмент.) И по-этому Кронос все операции с данными сопровождает локами на запись. А может и не по-этому, может разработчики не знали, что есть разные типы локов?
Но большая часть действий Кроноса проходит без перезаписи данных. Это касается и системных файлов Кроноса тоже. Мало того, если требуемый участок файла залочить не удается, то Кронос начинает тупо требовать блокировку повторно, пока ее не получит, сильно нагружая при этом локальную сеть.
Можно провести простой тест. Засунуть банк в сеть, и на клиенте запустить поиск по неиндексируемому полю базы. (Просто в этом режиме лучше всего проявляются эти проблемы.) Допустим база b04.* содержит 500000 записей. Процедура поиска проходит следующие этапы:
1. Установка лока на область 0-4 файла .tad.
2. чтение b04.tad для поиска адреса очередной записи.
3. чтение b04.dat, возможно несколько раз, если запись фрагментирована, для изымания записи.
4. снятие блокировки.
5. анализ вынутой записи на соответсвие критерию поиска.
6. очередная запись++ ; переход на пункт 1.
Если такой запрос выполняется с единственной станции, то время поиска занимает, например 5 минут. (Все цифры условны). При этом тупое копирование файлов b04.* на локальный диск занимает 1 минуту. Т.е. сеть не нагружается полностью даже 4-мя одновременно делающими один и тот-же запрос клиентами. Но! Запуск такого запроса одновременно с двух-трех клиентов увеличивает время поиска на каждом почти в 2-3 раза! И это происходит именно потому, что если кто-то один начал читать данные, то никто уже к ним подступиться не может до окончания процесса. Мало того, все остальные еще и загаживают сеть постоянными требованиями блокировок.
На таких тестах я хотел проверить, все-же, под какой ОС сервер лучше всего держит нагрузку. Для одного клиента лучше всего в качестве сервера шел ВинНТ или ОС/2 или Уних+Самба, по той простой причине, что клиент Вин умеет кешировать сетевые файлы, если они открыты только одним клиентом. Кеширующего клиента для Новелла у меня тогда не было. Но при нагрузке из трех и более клинтов, только Нетварь не снижала сильно быстродействие. И уже с 3 клиентов, по среднему времени поиска она выходила на первое место (а может и с 2,- не помню уже). Конечно сильное падение быстродействия наблюдалось, но где-то на 7-8 клиентах, но это уже виновата была сеть - в 10 Мбит этот трафик уже не влезал... Но, как ни странно, самым лучшим инструментом для исследований оказался Линукс с прикрученным к нему эмулятором Нетвари - Марс эта штука зовется. А хороша она потому, что есть вся в исходниках и можно править ее как угодно. (Правда с Самбой можно делать все тоже самое, но сделав один раз на Марсе, повторять на Самбе желания у меня не возникало...)
Первый шаг был - изменение программы сервера, для того? чтобы она анализировала блокировки, которые ставит клиент. И если это блокировка на промежуток от 0 до 4 (это те локи, которые Кронос ставит всегда и везде при любом обращении к данным), то я менял ее тип на такой который возвращал управление только после удачной блокировки, а если залочить не удается, то ответ не возвращается. Кронос все равно, получив ответ о неудаче такой блокировки, тут же требует ее опять...
Эта операция значительно разгрузила сеть при одновременном выполнении запроса 4 и более клиентами.
Дальше больше. По некоторым локам можно определить, что Кронос будет сейчас делать - только читать, или читать, а потом писать. Вариантов таких локов существует много и они чередуются с обычными, поэтому пришлось вводить для каждого клиента счетчик. Он считал локи, которые говорят, что будет проводиться запись Кроносом. (Это блокировки файлов .tad с отрицательными смещениями). Если этот счетчик больше 0, то все блокировки я ставлю на запись, если же счетчик = 0, то для блокировок (как правило локи 0 -- 4) я меняю тип на лок на чтение. При этом получается, что клиенты, ведущие чтение, вообще друг-другу не мешают!
А как выросла скорость одновременной работы при этом!
Да, а в Марсе есть еще одна фенечка! Если пользователю дать права на файлы данных только на чтение, то Марс для Кроноса будет открывать файлы только на чтение, и(!) при этом сам будет автоматом менять тип блокировки на "лок на чтение". Т.е. для таких клиентов даже ничего в сервере переделывать не надо.
(с) Сергей Сединкин, 2000 г.
PS У Вас всегда есть возможность высказаться в форуме.
