» HandyCache ( Часть 5 )

Цитата:

как тогда поступить с CD, а тем более с DVD

сомнительно, что когда лазишь в инете, нужен DVD и наоборот. Потому спокойно подключаем второй диск на 2-й канал master'ом, а DVD - slave'ом

Цитата:

Для SATA (Serial-ATA) же вроде бы на каждом канале - один девайс

Именно. Но никто (ничто) не мешает один диск иметь IDE, а другой - SATA. Лишь бы он был в наличии да мама была родная

Varenik
Цитата:

сомнительно, что когда лазишь в инете, нужен DVD и наоборот. Потому спокойно подключаем второй диск на 2-й канал master'ом, а DVD - slave'ом

Я ж не об этом... Ну ладно, у меня всего только 2 IDE-канала, SATA и не пахнет...
Но держать главный (рабочий патамушта) жёсткий диск (там, где всё, что нуна
лежит, на системном - только система и проги) на одном шлейфе с CD/DVD ?
Увольте. А уж каждый раз их передёргивать... Не-е-е-е...
Как говорится, "гондурас лучше руками не трогать, чтоб не беспокоил"...
Я уже точно сплю... *ночью дежурил*
Два винта, особенно если между ними ничего мега-гигабайтного постоянно не переливается,
по моему разумению, вполне могут и на одном шлейфе жить, так ведь?
Вот и пусть кэш HC не на системном и будет...
*чо вы меня всего путаете* (тихо ворчу басом)

rPansa

Цитата:

Но держать главный (рабочий патамушта) жёсткий диск (там, где всё, что нуна
лежит, на системном - только система и проги) на одном шлейфе с CD/DVD ?
Увольте. А уж каждый раз их передёргивать... Не-е-е-е...

Я понял, что он имел ввиду не системный диск держать с CD\DVD, а тот что с кешем HC.

forever
ded55

Цитата:

подвержена дефрагментации

Может имелась в виду фрагментация?

Производительность NTFS выше FAT при соблюдении двух важных условий. 1. Нужно много оперативной памяти. 2. Должно оставаться достаточно много свободного места. Иначе фрагментация катастрофически растет.

rPansa

Цитата:

Если это NTFS - так поступать не стОит однозначно.
Файлы маленького размера на NTFS хранятся в MFT, вместе с записями о них.

Разве размер зависей MFT зависит от размера кластеров?

Давайте уже сабж обсуждать. Тут пошел полный

Резюме?
-Про "битые" кластеры пропускаем...
-Кэш на отдельный диск(у кого какой есть - по возможностям).
-Дефрагментируем NTFS.
-Очень рекомендуется RAXCO PerfectDisk.
-Советы DenZzz актуальны.
forever
Цитата:

Пожалуйста на "ты".

-вижу достойного человека - пожалуйста, мы теперь на "ты".
Хочется надеяться, что этот симпозиум даст практические результаты участникам этого топика.
abz понял что мы имели ввиду.

Пооффтоплю уж ещё немного чтоб всё ясно стало...

C0USIN
Цитата:

Разве размер зависей MFT зависит от размера кластеров?

Нет, я про наоборот что лучше не делать кластер меньше рекорда в MFT (нет особого смысла). А при форматировании некоторыми не-M$ средствами можно ещё и выбрать размер записи в MFT...

ded55
В точку.
То есть можно сказать, что в смысле обсуждаемого пришли к конечному
решению, вернее - к реально выполнимым рекомендациям.
Дальше - уже дело каждого, следовать им или нет.

Цитата:

он имел ввиду не системный диск держать с CD\DVD, а тот что с кешем HC

вот именно. И, кстати, если (на второй диск) туда перенести своп-файл - тож будет недурственно

abz, Varenik
Да ёклмн у меня вдобавок (к свопу и кэшу HC)
на том жёстком диске как раз всё, что на болванки просится
Понял уже, о чём вы говорите, так что данный вопрос снят с повестки дня.
Вот когда третий хард поимею - однозначно туда это всё перенесу
и так и сделаю, как советуете (спс кстати).

Здравствуйте товарищи, извините форум листать нету времени, на оффоруме и в факе ответа не нашел.
В общем кеш разросся до 500 метров и предположительно из за этого винда при каждом старте тормозит минут на 5. Проблема скорее всего в HC. зависает при загрузке. То ли он кеш инспектирует то ли что? Спасибо.

У тебя NTFS? А создание марки времени и имен файлов в формате 8.3 для NTFS включено?

Цитата:

Когда Windows NT создает список каталогов (Проводник, команда DIR, и т.д.) в разделе NTFS, она модифицирует марку времени последнего доступа на каждом обнаруженном каталоге. Если каталогов очень много, это может повлиять на эффективность. Включив данный параметр вы можете немного ускорить работу системы c разделами NTFS. Данная опция работает только с дисками с файловой системой NTFS. На работу FAT32 никак не влияет. Чтобы узнать файловую систему диска, щелкните правой кнопкой на имени диска в Моем компьютере и выберите пункт меню свойства. Расположение: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem - NtfsDisableLastAccessUpdate

Этот параметр останавливает работу части NTFS, отвечающей за создание совместимых с МС-ДОС имен файлов в формате 8.3 . Отключение этого свойства может увеличить эффективность работы в разделах NTFS, с большим количеством файлов имеющих длинные имена. Предупреждение: Некоторые 16 разрядные инсталляционные программы могут иметь проблемы при включении этого параметра, Вы можете или заново включить создание 8.3 имен файлов в течение установки, или использовать имена каталогов не в формате LFN, то есть "c:\progra~1\applic~1". Расположение: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem - NtfsDisable8dot3NameCreation

У меня кеш 0,8Гб без проблем

ZONE51

Цитата:

кеш разросся до 500 метров

Это много, а в нем у Вас случаем закачки не хранятся?
На этой странице, чуть выше, этот вопрос уже рассмотрели и составили краткое резюме.

у меня кеш около 10Гб
ни каких проблем не возникало
разве что эффективность в последнее время упала с 40% до 21%
причину пока не нашел.

vortex0220

Цитата:

эффективность в последнее время упала с 40% до 21%
причину пока не нашел.

На своей практике убедился - эффективность понятие относительное.
Зависит, например от того, ходишь по одним и тем же сайтам или по разным.
Если ходишь все время по разным страницам, про эффективность говорить не приходится.
То есть пока в кэше страницы нет:
-из кэша ни чего не идет
-соотношение из кэша/из инета низкое.

Цитата:

у меня кеш около 10Гб ни каких проблем не возникало

А я и не говорю что большой кэш плохо, я спросил не наполнил он кэш закачками - ну например программами скачанными из инета, то есть бесполезным балластом.

rPansa

Цитата:

Подчеркнутое - очепятка?

Да, конечно. Имелась в виду фрагментация, а не дефрагментация.


Цитата:

Внеклассное чтение слехка устарело

Да, устарело. Например, инфа о том, что стандартный виндузовый API дефрагментации оперирует только блоками по 16 кластеров актуальна для w2k, но не для win XP.


Цитата:

Ответ на вопрос 4 - использовать не стандартный АПИ дефрагментации, а, например, PerfectDisk...

Дык хохма в том, что _все_ дефрагментаторы используют именно стандартный виндузовый API дефрагментации. И по сути являются просто разными надстройками над одним и тем же. Раньше нортоновский SpeedDisk имел свой API но после наезда MS и он был вынужден пересесть на стандартный API.
Может моя инфа устаревшая, но тогда хотелось бы увидеть подтверждение того, что PerfectDisk использует API отличный от стандартного.


Цитата:

Вопросы 2 и 3 - весьма провокационны

В чем же провокация? Кэш содержит десятки тысях мелких файлов большая часть из которых < стандартного размера кластера (4К). Поэтому и вопросы "адаптированы" под наши конкретные нужды.

C0USIN

Цитата:

Разве размер зависей MFT зависит от размера кластеров?

По версии MS именно так:

Цитата:

The MFT record size depends on the disk cluster size but is usually 1024 bytes. The file size that fits within the MFT record depends on how much space is left in the MFT record after accounting for the file metadata.

Перевод (мой):

Цитата:

Размер записи MFT зависит от размера кластера на разделе, но обычно составляет 1K. Размер файла, который хранится непосредственно в MFT, зависит от количества свободного места в записи MFT оставшегося после заполнения метаданных файла.

Источник

Еще наверное всем будет интересно почитать Windows XP Professional Resource Kit - Working with File Systems разделы Defragmenting NTFS Volumes и NTFS Data Structures (Master File Table and Metadata Files)

forever
Цитата:

В чем же провокация?

Да просто потому, что они риторические для меня, ибо вариант ответа один.

Цитата:

Может моя инфа устаревшая, но тогда хотелось бы увидеть подтверждение того, что PerfectDisk использует API отличный от стандартного.

Да нет, не имеет просто умеет намного больше (в частности - более умная оптимизация под загрузку, оффлайн дефрагментация, упорядочивание по датам) и пошустрее, но не в случае с упорядочиванием...
Хотя именно эта фишка и есть главная ИМХО. Потому как и имел её в виду, говоря (ошибочно) о нестандартном АПИ дефрагментации. Тут скорее налицо другой стратегический подход к вопросу

Тут уже почти полный оффтоп пошёл, однако надо завязывать
Просто дам в завершение пару линков, чтобы интересующимся разобраться:

1. http://www.raxco.com/ - сайт производителя.
2. Raxco Software PerfectDisk - обсуждение у нас на руборде.

Добавлено:
И еще линк - прямой на features

Кхм, глобальный оффтоп начался с маленькой фразочки.
Но разберем уж с начала и до конца.
ded55

Цитата:

Дефрагментация дисков это не субъективное восприятие, а техническая необходимость и объективная реальность.
Но Вам с этим соглашаться необязательно.

Вообще говоря, я сомневался с тем, что благодаря дефрагментации и размещению кеша на отдельном диске удалось добиться реального, заметного на глаз ускорения работы. А с тем, что дефрагментация нужна, вполне согласен.
Далее по-поводу NTFS - рекомендация форматировать кластеры 512 байт, очень даже имеет место быть. Потому что подавляющее большинство файлов имеет размер чуть больше 1-4кбайт (на оффоруме DenZzz приводил данные о среднем размере файла ~4.5кбайт, а у меня получается 22.5кбайт), поэтому эти файлы не сохраняются в МФТ и хвосты остаются ~размер кластера на каждый файл, а это ~300тыс файлов (в моем случае). Причем когда я переносил примерно год назад кеш на отдельный диск (с диска, где кластер был кажется 8кбайт) - получил экономию порядка сотен мегабайт.
Теперь дефрагментация - ну скажите мне, какая может быть дефрагментация, если на диске тысячи файлов, и каждый размером в пару кластеров? Тут даже в крайнем случае (размер кластера 512 байт, размер файла килобайт эдак 10 и каким-то чудом он оказался разбит по одному кластеру по всему диску, чего на нтфс не может быть из-за алгоритма worst fit) мы будем собирать файл из 20 кусочков, а потом целых полсекунды отрисовывать строчку в мониторе
Вот исходя из всех этих соображений я и сказал

Цитата:

Осмелюсь не согласиться, и списать улучшение на субьективность восприятия

И предлагаю закрыть тему, ибо дисковая подсистема НЕ является узким местом в работе НС. Кто сомневается - performance counters в руки

forever

Цитата:

Может моя инфа устаревшая, но тогда хотелось бы увидеть подтверждение того, что PerfectDisk использует API отличный от стандартного.

Ты абсолютно прав


Цитата:

Размер записи MFT зависит от размера кластера на разделе, но обычно составляет 1K.

Отсюда вывод - размер записи MFT всегда будет не меньше 1Kb. Значит ничего страшного если кластеры по 512 байт. Ведь так?

Добавлено:
cepera ang
Кэш состоит не только из файлов, но и из каталогов. Которых очень и очень много. А некоторые еще и большие. Дефрагментация папок и размещение их в одном месте заметно ускоряет работу.

C0USIN
Цитата:

Цитата:
Размер записи MFT зависит от размера кластера на разделе, но обычно составляет 1K.

Отсюда вывод - размер записи MFT всегда будет не меньше 1Kb. Значит ничего страшного если кластеры по 512 байт. Ведь так?

Ну, добавлю свою последнюю копейку...

Разжился тут стареньким Макстором 10Г, и пустил его на проверку. Отформатировал стандартными средствами под WinXP: NTFS, кластер 512. Проверил - рекорд MFT 1024. Насоздавал папок штук 500 с разным вложением, в каждой - по 500 файлов случайного размера от 1 до 511 байт.

Проверил - около 70% файлов "прописались на проживание" в MFT. Потери на "хвостах" для оставшихся составили около 8М. Простой подсчет в уме (или с калькулятором, кому как ) при сравнении с таким же диском, но с кластерами 1024, даёт в "хвостах" около 45М.

Выводы делайте сами Моё ИМХО - конечно, "ничего страшного", но овчинка выделки не стОит, разве что кто "за мухами" хочет погоняться Что я и говорил ранее. Экономия - мизерная (по сравнению с размером диска, даже если он и будет на порядок меньше). Кластеры 2048 - да, это уже зло, но и они ещё терпимы.

Цитата:

Кэш состоит не только из файлов, но и из каталогов. Которых очень и очень много. А некоторые еще и большие. Дефрагментация папок и размещение их в одном месте заметно ускоряет работу.

О! А это ещё один АГРОМАДНЫЙ плюс в пользу использования PerfectDisk'а !!!
Он-то ведь как раз и папки в одну кучу собирает, а штатный дефраг - нет.

Добавлено:
Вот если бы и размеры записей в MFT тоже стали бы по 512 - тогда да. Но - низя
А так получается, что те файлы, которые бы и дали max эффект, осели в MFT...

Ещё добавлено:
Честно говоря, тест, конечно, синтетический получился - не было файлов других размеров, бОльших 512. Но думаю, это не особенно важно. Кстати, поделитесь, кто сможет, гистограммками (табличками), сколько у кого в кэше HC файлов какого размера, а? (в личку, ессно) Только не в %, а примерно так: <512 - n1, 512-1024 - n2, 1024-1536 - n3 и т.д. Желательно до 4К с шагом 512, выше - *2, т.е. 4-8K - xxx, 8-16К - yyy, 16-32К - zzz, ... Появилась тут одна идейка...

И ещё добавлено:
Блин, поковырялся тут со своим кэшем, что на FAT32, и понял - исходных данных не хватает...((( Нужны ещё данные по тому, сколько в каждом диапазоне картинок/текстов (не картинок)... Чтобы упрОстить - к картинкам можно отнести только gif/jp(e)g/png/swf, всё остальное - к текстам Просто грядёт скоро переброс кэша HC на NTFS, и хочу попробовать, сколько сэкономится места, если кое-что выборочно сделать сжатым. Тут интересно как раз не столько быстродействие (вернее, не только) кэша, а реальная экономия места. У меня кэш сейчас около 600М, и я думаю, что реально будет без особой потери скорострельности ужать его процентов так на 20-30. Для работы в оффлайне это по моему актуально, да и ХРшный АПИ сжатия жмёт ведь те файлы, которые уже не изменялись больше месяца...

rPansa

Цитата:

ХРшный АПИ сжатия жмёт ведь те файлы, которые уже не изменялись больше месяца...

Как это? Можно подробнее? Можно сжимать файлы в кэше выборочно? Например jpg и gzip не трогать, а текстовые данные сжимать?

Когда будет исправлены ошибки?

Постоянно выскакивает "Access violation at address 005370D3 in module 'HandyCache.exe'. Read of address 0000045D"

vortex0220

Цитата:

Постоянно выскакивает "Access violation at address 005370D3 in module 'HandyCache.exe'. Read of address 0000045D"

Наверное эти ошибки персональные.
У себя такую ни разу не видел...

C0USIN
Дак а кто мне мешает только для нужных файлов (немаловажный для меня плюс - ещё и нужного размера) выставить атрибут "Сжатый", а потом уже окончательно пройтись по кэш-диску Микрософтовским Очистителем со сжатием ??? Лежат же в %windir%\system32\ и сжатые, и несжатые файлы (я диск С после долгих колебаний всё-таки сжал, и не жалею).

Сразу оговорюсь - FAR у меня в качестве универсального инструмента, а с его помощью с файлами ИМО можно практически всё что хошь вытворять, желательно в разумных пределах конечно. Проводником, и даже Total Commander'ом подобного с такой эффективностью ИМХО не сделать... (В нашем случае - найти все файлы с такими-то расширениями такого-то диапазона размера и присвоить им атрибут "Compressed". Ну или не с такими-то расширениями...)))

Вот и хочу поэкспериментировать, перед тем как на NTFS диск кэш переброшу.

Эх... вот придется только резервную "дырку" в разделах на диске заюзать
Макстор уже ушёл от меня по назначению...

Добавлено:
В принципе недолго для таких нужд (обатрибучивания ) "на коленке" что-нить типа утилитки командной строки состряпать, или даже гуёвой, но для меня оно не нужнО - FAR имеется

rPansa

Цитата:

окончательно пройтись по кэш-диску Микрософтовским Очистителем со сжатием

Ах да. Забыл про него. У меня кэш сжат целиком. Проблем со скоростью нет.
Но на будущее, не отказался бы, если HC сам будет проставлять аттрибуты сжатия в зависимости от типа данных.

C0USIN
Цитата:

У меня кэш сжат целиком. Проблем со скоростью нет.

Если так - это очень хорошо! Полюбопытствую: а сколько экономится?

Цитата:

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

+1, тогда можно и в ToDo-лист записАть что-нить типа:

Выставлять для (текстовых) данных, оседающих в кэш, атрибут "Compressed",
если файловая система NTFS (естественно - опционально). В качестве
критерия использовать расширения и/или инфу "Content-Type".

Добавлено:
Если скорострельность кэша не падает - можно от выборки по размеру отказаться
(это я так - для себя, просто поэкспериментировать хотел...)

Ну никак не получается у меня подружить НС с одним форумом. Каждый раз при перезагрузке страницы вся страница (кроме нескольких изобр.) грузится полностью из сети, даже если она не изменилась. Весит страница 170 кб - трафик 150-160 кб, несколько картинок берется из кэша и все. На том же Ру-боарде в подобном случае трафик 20-30 кб на страницу.
Да еще и сохраняться эти страницы в кэше стали через раз. У меня Опера, обычно сохраняю сессию из 20, а то и 30 страниц, из них с этого форума штук 7. Запускаю браузер офлайн - ВСЕ страницы как огурцы, а из этих семи только 2-3 открываются, остальные - Not found. Игнopиpoвaть No-cache стоит. Не обновлять для этого форума правило:

#5#~#False#~#.*#~##~#contr.communityhost.ru#~#00:05

Плюет он на это правило почему-то.
Есть другой форум, на котором я бываю даже чаще, чем на этом. В итоге в кэше communityhost.ru занимает около 17 мб, а этот другой около 3 мб!!! Причем там все работает прекрасно. Да, собственно, все другие сайты ведут себя хорошо и с НС дружат.
Да, еще. Пока браузер не закрыл, в офлайне хожу по тем страницам, где был, без проблем. Перезапускаю браузер - больше половины страниц Not found.

Мужики, помогите разобраться! Может, правило какое хитрое ему надо для этого сайта!

ЗЫ. На этом форуме стоит какой-то движок сырой довольно, это мне админ сообщил, может в этом дело?

Frank_Sinatra

Цитата:

Весит страница 170 кб - трафик 150-160 кб, несколько картинок берется из кэша и все. На том же Ру-боарде в подобном случае трафик 20-30 кб на страницу.

Это значит только то, что GZip на этом сайте не используется.

Цитата:

2-3 открываются, остальные - Not found

Возможны два варианта.
Страница в кэше есть но HC ее не находит.
Страница изначально не записалась в кэш. Проверяй правила в списке Запись в кэш.
Срабатывают ли они на этих URL?

Цитата:

#5#~#False#~#.*#~##~#contr.communityhost.ru#~#00:05

Странное правило. Да еще и выключенное. Может лучше так?
#5#~#True#~#contr\.communityhost\.ru#~##~##~#00:05

rPansa

Цитата:

Полюбопытствую: а сколько экономится?

Папок
Файлов
Размер файлов
Упакованный размер
Степень сжатия
Размер кластера
Реальный размер
Остатки кластеров 56635
222022
4,471,728,452
3,747,648,925
83%
512
3,793,886,720
46,237,795 (1%)

C0USIN

Цитата:

Это значит только то, что GZip на этом сайте не используется.

Где его искать, чтобы включить, подскажи. Если, конечно, GZip там вообще присутствует. Админ там ненамного больше меня в этих делах соображает.

Цитата:

Цитата: #5#~#False#~#.*#~##~#contr.communityhost.ru#~#00:05

Странное правило. Да еще и выключенное. Может лучше так?
#5#~#True#~#contr\.communityhost\.ru#~##~##~#00:05

Подскажите пожалуйста.
Необходимо чтобы handycache не обращался к определенному диапазону адресов типа xxx.xxx.xxx.xxx маска yyy.yyy.yyy.yyy через внешний прокси. Что прописать в поле "условие" в разделе "условные прокси"?

Frank_Sinatra

Цитата:

Где его искать, чтобы включить, подскажи.

Ищи в документации вебсервера про gzipmod. Больше ничем подсказать не могу

Vizautneim
Использовать IP-адреса в условиях пока никак не получится. Будет реализовано в будущем, надеюсь.

C0USIN
за инфо... ага.. значит, процентов 15-20 вполне реально сэкономить!
И это даже на кластере 512 - читал где-то, что сжатие ненапряжнее (ну и повыгоднее
естественно ) на дисках с кластерами именно станд.размера, т.е. 4К,
но оно нам не надо.

Что ж, буду исходить из выработанных рекомендаций и здравого смысла - под кэш HC
отведу логический диск NTFS гигабайт на 8, с кластером 1024.. а то сейчас часто
приходится чиститься, уже давно места кэшу не хватает под мои аппетиты