LibGen - Библиотекарь для "Library Genesis".

Kolian насчет ускорения это лучше обратиться на сайт разработчика. у меня не совсем корректная ситуация настроить под Вас - я не под Виндой, а под вайном с юникса

Ускорить... Я имею подозрение, что проблема в нескольких вещах (и программа тут не при чем).
У меня тоже книги лежат на сервере под линухой, программа - под виндой, обращается к архивам по сети. Алгоритм обращения достаточно простой. Я не знаю, как в данном конкретном случае происходит сканирование и распаковка. Если прям на сервере (НАСе), не скачиваясь - нагрузка идет на дисковую систему сервера, если предварительно винда его скачивает во временный каталог - нагрузка идет на сеть.
Ускорить можно только сделав дефрагментацию файловой системы, на которой лежат книги.
Если вопрос о скорости открытия книги - (30-40 Mb/s - это мегабиты?) Тогда 4 мегабайта в секунду - это достаточно медленно, если книга большая. И, как я понимаю, у НАСа скорость работы винта достаточно медленная, в некоторых НАСах вообще стоит преобразователь USB-SATA, т.е. скорость вообще маленькая относительно реального контроллера SATA.

NAS Synology DS-411j. Внутри 4 трехтерабайтных диска (SATA-3 3Tb Hitachi 7200rpm [HDS723030ALA640] Cache 64MB) завязаные в RAID-5. NAS связан с компом через гигабитную сеть (гигабитная сеть поддерживается с обеих сторон).

Synology DS-411j в тестах на сайте (Synology) заявлено чтение: до 100 мегабайт; запись: до 40 мегабайт.

Но чтение в лучшем случае делает для массивных файлов до 45-50 мегабайт. Запись 25-30 мегабайт.

Библиотекарь лежит на дескотопе (HDD 130 мегабайт чтение/100 мегабайт запись). Сканирование и распаковка базы (Я так понимаю) идет на локальном диске десктопа.

При нажатии клавиши ввод обращение идет к сетевому диску, где и лежит книга. Т.е. в место нажатия клавиши ввод, можно просто найти данную папку "ручками" и открыть нужных файл MD5. Получается быстрее...

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

Т.е. скорость низкая именно при попытке открыть уже имеющийся файл? А какое количество файлов в каталоге? Книги - каждая отдельно? И, сколько времени, приблизительно уходит на открытие книги (желательно, мелкой, что бы понять, сколько времени уходит именно на поиск)? Вот это и странно... NAS, как я понимаю, под линуксом? А какая файловая система на нем?

Номер книги 31401 (820 кб). 10 минут на открытие....

(файл лежит в папке тысячнике 31000, которая лежит со всеми остальными тысячниками на NAS)
(торрент был выключен...)

Файлов в каталоге 31000 - 1000, а в каталоге lib на NAS (куда входит каталог 31000) находится 720 каталогов. И, соотвественно, в каждом по 1000 файлов.

NAS линуксовый. Файловая система EXT4.

Скорее всего проблема с количеством файлов в каталоге. Но почему винда эти каталоге лопатит с легкостью...?

Тогда всё понятно. EXT4 - не самое быстрое, журналируемое (рейзер быстрее) Программа сканирует все подкаталоги (а когда вынью входишь - один) Соответственно на получение списка файлов уходит туева хуча времени... Поскольку далеко не все хранят инфу в разбитых на подкаталоги структурах - оптимизировать (а я думаю, раз в 10-20 как минимум по времени) не получится Либо всех заставить хранить файлы в единой структуре (что весьма сомнительно), либо ждать по 10 мин...

Предусмотрено только EXT3 и EXT4.

Вот его спецификация http://ukdl.synology.com/download/ds/DS411j/DataSheet/Synology_DS411j_Data_Sheet_rus.pdf

Печально...

Да я смотрел, тут проблема в огромном количестве файлов, тормоза дикие возникают именно при сканировании такого кол-ва каталогов и файлов... К сожалению, без единой для всех четкой структуризации каталогов, где поиск будет осуществляться только в одном каталоге, оптимизировать поиск однозначно не удастся. Если же поиск будет проходить в одном каталоге (с максимум тысячей файлов) скорость возрастет на 1-2 порядка.

А Вы как вопрос с окрытием файла решаете? Может быть вы файлы хитрым образом размещаете?

И можно спросить сайт производителя?

Все нашел... Спасибо...

http://libruslib.ucoz.com/forum/31-80-38

"можно ли сделать кеширование или индексацию репозитория который находится на сетевом диске? 5-10 мин. приходится ждать открытия книги."

Главное не допускать высокой фрагментации... А по поводу размещения - я подумаю, может какая идея придет. Плохо, что в имени файла отсутствует ID файла, по MD5 как-то группировать нелогично...

согласен... может винде отправит запрос как в дос... типа: "acrobat путь к файлу..." или "windjvu путь к файлу..."

>>Плохо, что в имени файла отсутствует ID файла, по MD5 как-то группировать нелогично...

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

недопонимаю я все таки... почему винде перескана каталогов не надо.

Есть в базе, но не в имени файла. Прийдется писать приблуду, которая будет создавать каталоги и перемещать файлы. Ты не понял, не в перескане дело. Когда работает программа, она пересканирует все файлы во всех каталогах, а когда ты напрямую входишь виндой - только один, в который ты входишь. Если все файлы сольешь в один каталог - и из-под винды будешь ждать 10-15 мин, пока откроется каталог.

Я читал ветку http://libruslib.ucoz.com/forum/31-80-38

Тебе видней... Ты Мастер...

Но я так понимаю если у тебя есть поле базы ID (столбец ID видно в библиотекаре), то для заданной книги можно извлечь его значение. ID известен, MD5 известен, папка с локацией книг известна. Можно не сканировать, а сразу отправлять на открытие.

в упрощенном виде:

a$="Z:\NAS\lib\"
b=ID (книги)
c$=right$(str$(int(b/1000)*1000),len(str$(int(b/1000)*1000))-1)
d$=MD5 (книги)
e$=a$+c$+"\"+d$

open e$

еще было указаны параметры сервака на котором желательно размещать скачанное...
"хм, а программа при чем? тормозит на уровне дисковой подсистемы... Купи комп по-мощнее, поставь штук 5-10 дисков в рейд, гектар 8 памяти, 6-8-ядерник проц.... получишь ускорение..."

6-8 ядер... я так понимаю скан каталогов хорошо распараллеливается? или нет? не получится так, что пахать будет 1 ядро.
тоже самое по поводу оперативы... скан каталогов остается в памяти, что дает возможность не мучить диски? я правильно понял...?

Да нет, я не мастер, я так, погулять вышел Именно. Я имел в виду, что у многих файлы свалены тупо в одном каталоге без структуры. И такой метод не прокатит. Для того, что бы работало у всех - у всех же должна быть единая структура каталогов, типа 1-1000,1001-2000... и т д... Вот тогда можно легко вычленить нужный каталог и значительно ускорить процесс... А тут вопрос неоднозначен... Если у пользователя (а таких большинство) пара сотен книг - то хватит самой простенькой, без всяких рейдов машинки... А вот если десятки, а то и сотни тысяч - тогда и серверок должен быть по-мощнее, рейд из 5 дисков ускорит процесс раза в 3-3.5 Ядра здесь действительно не очень важны, главное, хотя-бы два... Скан в памяти останется разе-что в кеше (это я заметил по либруслибу), но на локальной машине а не на сервере. Я писал про ядра и память, имея в виду то, что и программа и контент на одном компе.

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

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