+  HandyCache форум
|-+  Главная категория» Общие вопросы» Баланс быстродействия: как уменьшить влияние медленного HDD?
Имя пользователя:
Пароль:
Страниц: [1] 2  Все   Вниз
  Отправить эту тему    Печать  
Автор Тема: Баланс быстродействия: как уменьшить влияние медленного HDD?  (Прочитано 19170 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Andrey_04.05
Новичок
*

Репутация: +3/-0
Offline Offline

Сообщений: 18


« : 20 марта 2013, 12:34:57 »

Приветствую всех участников форума! Хочу выразить благодарность автору за такую действительно клевую программу! Пользуюсь около года. Решаю несколько задач:
1. Для раздачи интернета (кабельный анлим) с Большого Главного компа (4 ядра по 3.00 ГГц, 16 Гб ОЗУ) на ноут. На Главном в кеш ничего не пишется, и ничего с кеша не читается.
2. На ноуте также стоит HC для "накопления" интернета ))) При приходе трафика от Главного в кеш пишется, но не читается. Иногда ноут работает в полевых условиях через 3G модем, вот тут то галочка "чтение из кеша" и устанавливается.
3. Кроме того, обкатываю на этой конфигурации некоторые подходы, правила, настройки. И после этого переношу их на компьютер сестре. У нее 3G модем, и кеширование - первоочередная задача.

Ноутбук и компьютер сестры - нормальные машинки: по два ядра, 2 и 4 Гб ОЗУ соответственно.
И потому очень хочется по максимуму использовать проц, по минимуму диск. Чтобы экономия трафика не приводила к увеличению времени загрузки страниц. В этом свете у меня возникло несколько вопросов (читал форум два дня, практически без перерыва, видел обсуждение рядом с моими вопросами, но не видел конкретных ответов. Не исключено, что просмотрел, сильно не ругайте. В частности, DIGGER в трех-четырех местах тоже выражал обеспокоенность производительностью HDD):

1. Пытается ли HC читать из кеша то, что он туда не писал? Например, правило №2 в белом списке отключает запись архивов, видео и др. Но будет ли HC при чтении проверять, имеются ли они на диске?

2. Пытается ли HC читать из кеша то, что он удалил как неподходящее по размеру? Т.е. то что меньше чем "не сохранять файлы меньше" или больше чем "не сохранять файлы больше".

3. Видел пару раз рекомендацию включать NTFS-сжатие. На чем основан вывод о его пользе? Понятно, что кеш будет занимать меньше места. Но ведь в любом случае каждый файл = обращение к диску (и не одно). Размер кеша меня не очень волнует. А не упадет ли производительность за счет постоянного сжатия-разжатия?

4. Каковы рекомендации к полю "не сохранять файлы меньше" и на чем они основаны? Интуитивно понятно, что мелкие файлы легче взять с сети, чем гонять винт. Но если при чтении все равно обращаться к диску с вопросом "есть такой файл или нет?", может пусть он там будет? Если я не ошибаюсь, мелкие файлы на томе NTFS хранят свое тело прямо в таблице MFT, а значит за одно обращение к диску получаем и ответ и его существовании, и его тело, так? Ну или программно это две разных операции, но когда головка уже в нужном месте на диске, вторая выполняется очень быстро. Если я не прав, поправьте, пожалуйста.

Немного позже хочу приложить статистику по распределению количества файлов в моем кеше в зависимости от размера файла. Писал в кеш около полугода с полем "не сохранять файлы меньше" равным нулю. Посмотрим, файлов какого объема больше всего в сети (по крайней мере в моей выборке сети Улыбка ). Хочу на ее основе совместно с участниками форума определиться с оптимальным значением этого поля.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #1 : 20 марта 2013, 14:30:55 »

1. Пытается ли HC читать из кеша то, что он туда не писал? Например, правило №2 в белом списке отключает запись архивов, видео и др. Но будет ли HC при чтении проверять, имеются ли они на диске?

HC не запоминает список файлов, которые он писал в кэш ранее. Поэтому, если архивы, допустим, есть в списке "Не обновлять", то HC будет их искать на диске, даже если в Белом списке стоит запрет на их запись. Ведь эти архивы могли попасть в кэш и другим путем: перенесены с другого компа, сохранены специально с отключенным на тот момент Белым списком, сохранены расширением, сохранены пользователем командой из Монитора HC и т.д.

Цитировать
2. Пытается ли HC читать из кеша то, что он удалил как неподходящее по размеру? Т.е. то что меньше чем "не сохранять файлы меньше" или больше чем "не сохранять файлы больше".

Да. HC не помнит размеры файлов, которые он не сохранил ранее. Кроме того, на момент поступления запроса, размер файла еще не известен.

Цитировать
3. Видел пару раз рекомендацию включать NTFS-сжатие. На чем основан вывод о его пользе? Понятно, что кеш будет занимать меньше места. Но ведь в любом случае каждый файл = обращение к диску (и не одно). Размер кеша меня не очень волнует. А не упадет ли производительность за счет постоянного сжатия-разжатия?

Уже обсуждалось в теме: http://handycache.ru/component/option,com_smf/Itemid,10/topic,664.msg5568/#msg5568

Цитировать
4. Каковы рекомендации к полю "не сохранять файлы меньше" и на чем они основаны? Интуитивно понятно, что мелкие файлы легче взять с сети, чем гонять винт. Но если при чтении все равно обращаться к диску с вопросом "есть такой файл или нет?", может пусть он там будет? Если я не ошибаюсь, мелкие файлы на томе NTFS хранят свое тело прямо в таблице MFT, а значит за одно обращение к диску получаем и ответ и его существовании, и его тело, так? Ну или программно это две разных операции, но когда головка уже в нужном месте на диске, вторая выполняется очень быстро. Если я не прав, поправьте, пожалуйста.

Все зависит от типа диска, файловой системы и размера кластера.

В MFT NTFS свое тело хранят только очень мелкие файлы, которые умещаются после всех атрибутов в размер одной записи. Если файл чуть больше или атрибутов у файла много, то для хранения этого маленького тела нужен уже целый большой кластер. Большая часть кластера окажется не использованной. Потери на остатках кластеров будут велики. Поэтому при больших размерах кластера мелкие файлы лучше не сохранять, т.к. дисковое пространство будет использоваться неэффективно.

Файловая система FAT32 критична к большому количеству мелких файлов и начинает сильно фрагментироваться и тормозить, поэтому на FAT32 мелкие файлы лучше также не сохранять.

Твердотельные диски SSD критичны к количеству циклов перезаписи, это снижает их ресурс, поэтому чем меньше пишешь на такой диск, тем лучше.
Сообщить модератору   Записан
Andrey_04.05
Новичок
*

Репутация: +3/-0
Offline Offline

Сообщений: 18


« Ответ #2 : 20 марта 2013, 15:21:49 »

HC не запоминает список файлов, которые он писал в кэш ранее. Поэтому, если архивы, допустим, есть в списке "Не обновлять", то HC будет их искать на диске, даже если в Белом списке стоит запрет на их запись. Ведь эти архивы могли попасть в кэш и другим путем: перенесены с другого компа, сохранены специально с отключенным на тот момент Белым списком, сохранены расширением, сохранены пользователем командой из Монитора HC и т.д.

И даже если их нет в списке "не обновлять", то все равно будет их искать на диске, верно? Чтобы узнать, не изменились ли они. Или не верно?
Добавлено: 20 Март 2013, 15:06:16

Да. HC не помнит размеры файлов, которые он не сохранил ранее. Кроме того, на момент поступления запроса, размер файла еще не известен.
Вопрос полностью исчерпан. Я так и предполагал )))
Добавлено: 20 Март 2013, 15:07:17

Уже обсуждалось в теме: ...
Спасибо, ознакомился. Это обсуждение мне не попадалось, хотя я думал за почти двое суток пересмотрел всё. Вопрос также полностью исчерпан - для себя решил, что не следует сжимать. Как вариант, если совсем критичен станет размер кеша, то сжимать только html-ки (сторонней программой либо периодически вручную).

P.S. почему при цитировании вместе с ссылкой выпало сообщение "В сообщении слишком много внешних ссылок."? Пришлось заменить на "...", хотя там только одна, и та не внешняя.
Добавлено: 20 Март 2013, 15:12:59

Все зависит от типа диска, файловой системы и размера кластера.

В MFT NTFS свое тело хранят только очень мелкие файлы, которые умещаются после всех атрибутов в размер одной записи. Если файл чуть больше или атрибутов у файла много, то для хранения этого маленького тела нужен уже целый большой кластер. Большая часть кластера окажется не использованной. Потери на остатках кластеров будут велики. Поэтому при больших размерах кластера мелкие файлы лучше не сохранять, т.к. дисковое пространство будет использоваться неэффективно.

Файловая система FAT32 критична к большому количеству мелких файлов и начинает сильно фрагментироваться и тормозить, поэтому на FAT32 мелкие файлы лучше также не сохранять.

Твердотельные диски SSD критичны к количеству циклов перезаписи, это снижает их ресурс, поэтому чем меньше пишешь на такой диск, тем лучше.
По моим наблюдениям, если писать в кеш все файлы подряд (я про размер, а не про тип), то как раз мелких очень много. Чуть позже, как обещал, измерю и выложу статистику. Но вот верно ли мое предположение, что раз все равно ищем на диске, присутствует ли файл или нет, т.е. обращаемся к MFT, то пусть он там присутствует? Давайте внесем ясность, что сейчас говорим именно про те файлы, которые уместились в записи MFT. Понятно, что для тех кто не уместился, будет явное увеличение дисковых операций: нужно будет прочитать начало, затем найти где лежит конец, считать конец. Или я в своем предположении чего-то не учитываю, и поэтому она неверно?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #3 : 20 марта 2013, 15:39:22 »

И даже если их нет в списке "не обновлять", то все равно будет их искать на диске, верно? Чтобы узнать, не изменились ли они. Или не верно?

Без надобности искать на диске не должен. Если запись в кэш не требуется, то без разницы изменился он там или нет - все равно он обновлен не будет.

Цитировать
P.S. почему при цитировании вместе с ссылкой выпало сообщение "В сообщении слишком много внешних ссылок."? Пришлось заменить на "...", хотя там только одна, и та не внешняя.

Новички не могут использовать ссылки. Защита от СПАМа.

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

В целом все верно.
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #4 : 20 марта 2013, 18:27:02 »

Хочу добавить, что в работе с дисковым кэшем участвует RAM-кэш. Даже если сам файл по размеру не подходит для хранения в RAM-кэше, информация о нем хранится в RAM-кэше. В RAM-кэше хранится информация о файлах в дисковом кэше, к которым было обращение в текущей сессии работы НС. Когда НС нужен какой-то файл в кэше или информация о нем, его поиск ведется сначала в RAM-кэше. Если в RAM-кэш нет информации, то тогда используется дисковый кэш.
Сообщить модератору   Записан
Andrey_04.05
Новичок
*

Репутация: +3/-0
Offline Offline

Сообщений: 18


« Ответ #5 : 25 марта 2013, 09:56:30 »

Всем добрый день. Вот, приготовил обещанную статистику. Кеш собирался в течении примерно полугода. в кеш писалось всё (по размеру). За это время набралось 142290 файлов общим объемом 2.235.743 кбайт (2.24 Гбайт). На приложенной картинке представлен график количества файлов в зависимости от их размера. Еще больше информации в "size.xls" по приложенной ссылке. Первое, что бросилось в глаза - в интернете много именно мелких файлов. На графиках видно, что половина файлов, осевших у меня к кеше, меньше 5 кбайт (!!!). Половина файлов. Около 70 000 штук. 32% от общего количества меньше 2 кбайт. Если возьмем 90% меньших файлов, по самый большой из них будет объемом 35 кбайт. Мелочь, блин, пузатая. Представляете как таблица MFT разрастается от такого количества мелочевки? Конечно, их хранить не хочется. Но ведь HC в любом случае ищет их на диске (((. А при скачивании все равно их туда пишет. Перед тем как сразу же удалить, если в настройках указано не хранить такую мелочь. Сколько обращений к медленному HDD ((( Или сколько терзаний для SSD (привет, Inversion). И из-за чего? 90% мелких файлов занимают 35% от  всего объема. Т.е. остальные 10% занимают 65% объема. Да, файлы из первых 90% будут встречаться чаще - во первых их большое количество в интернете, во вторых их большое количество в кеше. Но каков будет выигрыш в объеме? Они крошечные и экономия от них крошечная. Ну и о каком быстродествии можно говорить? Шокирован

Правила форума не дают привести ссылку на "size.xls". Я его залил на файлообменник sharemania, домен ru под номером 0233483.


* скрин.JPG (48.48 Кб, 970x604 - просмотрено 112 раз.)
Сообщить модератору   Записан
Andrey_04.05
Новичок
*

Репутация: +3/-0
Offline Offline

Сообщений: 18


« Ответ #6 : 25 марта 2013, 12:03:39 »

P.S. Не обозначил на графике оси. Без обозначения сходу не разберешься, что к чему. По оси ОХ отложены размеры файлов в килобайтах. По оси ОУ количество файлов данного размера, в процентах от общего количества.

P.S.2 И еще раз более внятно про "size.xls": лежит на файлообменнике "sharemania", домен "ru", номер файла 0233483. Нужно просто скомпоновать из имени файлообменника и домена ссылку, пройти по ней, и в поле "номер файла" вставить 0233483. После этого жмем "скачать". Хотя наверно зря я так подробно, потенциальные читатели этого форума более чем уверенные пользователи )))
Сообщить модератору   Записан
LordMerlin
Старожил
****

Репутация: +12/-8
Offline Offline

Сообщений: 488


« Ответ #7 : 25 марта 2013, 15:57:41 »

И что же вы предлагаете в итоге делать?
Сообщить модератору   Записан
Andrey_04.05
Новичок
*

Репутация: +3/-0
Offline Offline

Сообщений: 18


« Ответ #8 : 26 марта 2013, 08:51:31 »

У меня есть определенные соображения. Хотелось бы обсудить их с опытными пользователями.
Когда я около года назад познакомился с этой чудесной программой, я пошел таким путем:
Писать всё на жесткий диск мне не хотелось сразу. Как раз из соображений производительности. Я к тому моменту уже пользовался рамдиском от Qsoft. Складывал туда всякую мелочевку, какие-то временные/промежуточные файлы, и т.д. Содержимое диска при выключении сохранялось в образ, при включении загружалось из него. Я сразу решил, что буду писать кеш туда. Особенно мне не хотелось дергать винт в тот момент, когда файл записался и тут же удалился ("200 OK POST" З.1, Deleted small file). Тут же, очевидно, сразу появлялись вопросы о заполнении диска, т.к. рамдиск очень большим быть не может. На ноутбуке, где оперативки всего 2Гб, под рамдиск отдано 256Мб. Они заполнялись довольно быстро, к тому же кроме кеша я там размещал другие файлы. Можно было периодически чистить кеш и оставлять в нем только "самое свежее", но мне было нужно больше. Мне было нужно не только "самое свежее", а как можно больше "накопленного интернета", чтобы в полевых условиях, через 3g модем можно более-менее работать. Разумеется, когда интернет подключен через модем, я уже не так заморачиваюсь про быстродействие HDD, там важнее экономия трафика как способ субъективного "ускорения" интернета. Вот и родилась мысль - копить кеш на винте. Но писать туда все время все подряд я все же не хотел. Тогда я набросал небольшую прогу, которая все время висит в памяти, периодически просматривает папку кеша на рамдиске (папка "b:\cache", периодичность зависит от заполненности диска "b"), и если находит файлы большее заданного порога (порог поставил в 512 кбайт), то перемещает его в кеш на HDD (папка "d:\cache", предварительно создав все промежуточные каталоги). Кроме того, если все тяжелые файлы перемещены, а места на рамдиске все равно мало (тоже задается порогом, у меня 25%), то перемещению подлежат 10 самых тяжелых файлов из оставшихся. Программка пишет в лог результаты операции, вот пример ее лога:

25.03.2013 14:48:50   free  24%/26%;   files  506/496;   schet  172 ms   move  219 ms;   rd  50;   pausa  300 s.
25.03.2013 14:53:51   free  25%/25%;   files  514/514;   schet  110 ms   move  -2 ms;   rd  96;   pausa  300 s.
25.03.2013 14:58:51   free  18%/20%;   files  520/509;   schet  141 ms   move  47 ms;   rd  71;   pausa  60 s.

Строка лога подобрана, чтобы умещаться у меня на экране в блокноте. Здесь дата/время, процент свободного места до процедуры чистки, через дробь после процедуры чистки. Далее количество файлов до очистки / после очистки. Далее время, потраченное на рекурсивный обход всего кеша, затем на перемещение файлов ( "-2 ms;" - перемещение не выполнялось). После этого количество удаленных пустых каталогов, и последнее значение - пауза до следующей процедуры очистки (зависит от заполненности диска).
Каталог "b:\cache" в HC стоит как основной. Каталог "d:\cache" - только для чтения. В таком виде у меня это все и проработало до сегодняшнего дня, и продолжает работать. Когда я только затевал написание этой вспомогательной программы, мне, конечно, говорили знакомые "когда коту делать нечего, он яйца лижет". Возможно, кто-то из форумчан подумает точно так же )))) Мне бы больше хотелось если и критики, то конструктивной. А лучше советов. Возможно, при этом подходе я чего-нибудь не учел, где-то сглупил, про что-то очевидное забыл. Выражайте свои мнения )))
Сообщить модератору   Записан
LordMerlin
Старожил
****

Репутация: +12/-8
Offline Offline

Сообщений: 488


« Ответ #9 : 26 марта 2013, 10:26:14 »

Дело в том, что ваша схема это переосмысление конструкции уже изобретенного велосипеда. В НС есть РАМ кеш, в который и из которого первоочередно все пишется и читается. После правильной настройки он хорошо работает, например в данный момент у меня он размером 187Мб. И тут, мне кажется, надо добавить в НС функционал по сохранению, пусть и опционально, этого кеша на диск и загрузке при старте.
Насколько я понимаю логика работы РАМ кеша достаточно правильная, там хранятся наиболее часто запрашиваемые файлы, и в нем же хранится инфа о расположении файлов в дисковом кеше.
Таким образом подгрузка образа РАМ диска при запуске даст из минусов это увеличение времени загрузки (что не страшно ведь можно сделать опцией) из плюсов кеш сразу начинает работать и сразу с самыми часто запрашиваемыми файлами, и остается инфа о расположении файлов в дисковом кеше.
Профит со всех сторон.
Осталось только разработчика упросить.
Сообщить модератору   Записан
Andrey_04.05
Новичок
*

Репутация: +3/-0
Offline Offline

Сообщений: 18


« Ответ #10 : 26 марта 2013, 13:42:42 »

Согласен с тем, что сохранение и загрузка встроенного RAM-кеша очень клевое дело. Но просят разработчика об этом уже давно. И наверно еще долго будем просить. mai62 уже высказывал на этот счет свои сомнения, и судя по всему он непоколебимо убежден в их серьезности, раз не сдается ))) Я пробую найти оптимальный на мой взгляд способ, который можно применять уже сегодня. У меня, как я писал уже, кеш на рамдиске уже стоит с полгода, и прекрасно работает. Да, этот способ подойдет не всем. Да, это дополнительная программа, вдобавок к уже имеющемуся НС. Да, она не снимает абсолютно все проблемы. Но те цели, которые перед ней ставились изначально, она выполняет. Все новые файлы ложатся в память, на диск НС не пишет ничего. На диск пишет только моя прога, максимум раз в минуту. И тем не менее, кеш на винте потихоньку копится, и тоже свою функцию выполняет.
Я бы хотел больше обсудить детали этого способа, где его еще можно улучшить:
Вот мне видится что расширение IgnoreOnceVisitedSites, написанное Inversion, можно настроить на хранение статистки на моем рамдиске, чтобы она загружалась заранее, и без ущерба для времени запуска НС.
Еще, здесь проходили обсуждения про сжатие кеша на NTFS. Я из них сделал вывод, что кеш целиком лучше не жать, лучше сжимать только html-ки. Мне практически ничего не стОит добавить в своей дополнительной программе эту функцию уже СЕГОДНЯ.
Далее, имеющийся рамдиск можно использовать для индексирования разного рода информации, о чем здесь говорят уже тоже очень много и долго (и тоже безрезультатно).
Сообщить модератору   Записан
LordMerlin
Старожил
****

Репутация: +12/-8
Offline Offline

Сообщений: 488


« Ответ #11 : 26 марта 2013, 14:17:55 »

Ждем комментарием разработчиков и конечно же вашу программу в общем доступе для тестов.
Сообщить модератору   Записан
DIGGER
Старожил
****

Репутация: +14/-3
Offline Offline

Сообщений: 312



« Ответ #12 : 26 марта 2013, 15:12:33 »

Почитал, посмотрел, подумал: попахивает велосипедом, увы…

Почему нет желания использовать возможность кэширования самой ОС?

Есть замечательная книга "Windows Internals". Читал 5-е издание (WinXP), а в Win7 I/O subsystem и Cache manager переработаны, можно лучше указать OS что и как кэшировать, и с каким приоритетом. А то получается: торренту выдели память для кэша, HC выдели память для кэша, браузеру выдели память для кэша; фотошоп уже и не запустишь((( не говоря о том что HC 32-битная программа – много не закэшируешь.

Торрент припинал: кэширует с низким приоритетом, нет вымывания часто используемых файлов из кэша. С HC так не получается ибо с I/O low Priority тормоза с инетом получаются, предпочитаю I/O high priority.

P.S. ОЗУ 8гиг и мне не хватает в пиковые моменты (подкачка отключена)
Сообщить модератору   Записан
LordMerlin
Старожил
****

Репутация: +12/-8
Offline Offline

Сообщений: 488


« Ответ #13 : 27 марта 2013, 10:03:30 »

Ну как бы и я о том же. Сейчас все хорошо, единственное хотелось всетаки сохранение РАМ кеша и его обратная загрузка при старте.
Сообщить модератору   Записан
DIGGER
Старожил
****

Репутация: +14/-3
Offline Offline

Сообщений: 312



« Ответ #14 : 27 марта 2013, 22:23:18 »

LordMerlin, сервис SuperFetch как раз этим и занимается в OS выше WindowsXP
Сообщить модератору   Записан
LordMerlin
Старожил
****

Репутация: +12/-8
Offline Offline

Сообщений: 488


« Ответ #15 : 28 марта 2013, 09:22:17 »

DIGGER
Не согласен. Вы немного заблуждаетесь.
SuperFetch запоминает, какие приложения вы используете больше всего и предзагружает их в память, добавляя вашей системе отзывчивости.
Это никоем образом не связано с обычными файлами. С файлами как раз работает кэш самой системы, тут не спорю, НО..при перезагрузке все слетает. Вот потому нам и нужен механизм восстановления состояния какого либо кэша, хоть виндового хоть НС. И опять НО, во первых я бы посмеялся глядя на попытки кого либо убедить Мелкомягких чтото изменить в ядре, да и бессмысленно по сути, ибо выборочное сохранение не сделать, а весь кеш грузить за предыдущий сейнс глупо.
А вот в НС это и более реально и более правильно.
Сообщить модератору   Записан
DIGGER
Старожил
****

Репутация: +14/-3
Offline Offline

Сообщений: 312



« Ответ #16 : 28 марта 2013, 17:32:43 »

Не согласен. Вы немного заблуждаетесь.
SuperFetch запоминает, какие приложения вы используете больше всего и предзагружает их в память, добавляя вашей системе отзывчивости.
Это никоем образом не связано с обычными файлами.
У меня, при старте системы, в память грузились все файлы скачанные торрентом аж пока не заполнялась вся оперативка. (не буду рассказывать чем этот процесс можно наблюдать) При отключении SuperFetch такого не наблюдается.
Не просто так мною была упомянута книга "Windows Internals".
Сообщить модератору   Записан
zed
Постоялец
***

Репутация: +4/-0
Offline Offline

Сообщений: 141


« Ответ #17 : 28 марта 2013, 21:32:36 »

Таки нужно смотреть в сторону БД. Что-нибудь вроде такого:

Цитировать
MemBase — открытое, распределенное персистентное хранилище ключ-значение оптимизированное для хранения данных веб-приложений.
    персистентен
    имеет квази-постоянное (quasi-deterministic) малое время отклика
    высокая скорость работы
    линейно масштабируется с одного сервера до тысяч
    не имеет схемы данных (только ключ-значение)
    совместим по протоколу с memcached
Сообщить модератору   Записан
Andrey_04.05
Новичок
*

Репутация: +3/-0
Offline Offline

Сообщений: 18


« Ответ #18 : 29 марта 2013, 13:57:16 »

Ждем комментарием разработчиков и конечно же вашу программу в общем доступе для тестов.
Залил прогу на шареманию, номер файла 0251889. Программа не предполагала распространения, поэтому не обладает "юзерфрейндли"-интерфейсом. Строго говоря, она не обладает никаким интерфейсом: запускается из командной строки и висит в памяти, выполняя свою работу. Окошек не имеет, стоит в автозапуске, выключается вместе с виндой (либо из диспетчера задач). В архиве с ней небольшой README.
Поведение:
Если места на рамдиске <10%:
   перебросить все файлы больше порога (512 кбайт),
   перебросить еще 10 самых больших файлов,
   назначить следующую проверку через 30 сек.
Если места на диске от 10% до 25%:
   перебросить все файлы больше порога,
   проверить свободное место, если снова <25%, перебросить еще 10 самых больших файлов,
   назначить следующую проверку через 60 сек.
Если места на диске от 25% до 75%:
   перебросить все файлы больше порога,
   назначить следующую проверку через 300 сек.
Если места на диске >75%:
   назначить следующую проверку через 600 сек.
   
Сообщить модератору   Записан
alex77
Старожил
****

Репутация: +11/-1
Offline Offline

Сообщений: 482



« Ответ #19 : 29 марта 2013, 14:22:58 »

120 кбайт можно было и тут прикрепить
Сообщить модератору   Записан
Страниц: [1] 2  Все   Вверх
  Отправить эту тему    Печать  

 
Перейти в: