Дефрагментация реестра?

А разве есть повод для изменения мнения? Я не вижу.

Вот это я и хотел услышать
У меня раньше стояла вот эта программуля RegistryBooster,постоянно автоматически,каждую неделю,находило примерно по 60 ошибок реестра,потом и исправляла их, значит толку мало от этой программы,исходя из ваших слов.......

Вернулся к данному вопросу, по дефрагментации реестра, прочитал кой какую информацию (как осуществляется запись и удаление ветвей из него, анализ по Microsoft Windows Performance Toolkit) с начало года поменял свое мнение по данному вопросу. Считаю что если остановиться на хорошей программе, то проблем не будет с данным процессом не будет, да и программы сильно изменились за данное время (про дефрагментацию).

Реестр (Registry) Реестр Windows или системный реестр — иерархически построенная база данных параметров и настроек. Со временем, большое количество ошибочных параметров реестра может приводить к сбоям и различным проблемам, мешая нормальному функционированию ОС. Программы постоянно сотни раз в секунду обращаются за данными расположенными в реестре ОС. Для увеличения производительности, ОС стремится минимизировать обращения к файлам реестра, кэшируя (загружая их в память ПК). Данные реестра хранятся в файлах расположенных по адресу: \windows\system32\config – например system, sam, security, software, default.
Если какая либо программа нам больше на ПК не нужна, то мы ее удаляем, а при ее удалении происходит удаление файлов самой программы и удаление записей в реестре о ее параметрах.
Для более полного понимания, что из себя представляет реестр - двоичное дерево которое состоит из ветвей и листьев, причем листья одного ветви могут располагаться в различных концах файлов реестра. Чтоб увидеть данные реестра в удобном виде можно воспользоваться программой regedit.exe
Реестр заполняется последовательно по мере добавления новых ветвей даже если добавление происходит к уже ранее созданной ветви, то она добавляется все равно в конец файла, в то время как родительская ветвь может быть расположена где угодно. При удалении ветвей реестра соответствующие им листья лишь помечаются как «удаленные» физической реорганизации данных при этом не происходит. (наподобие как удаления файлов). Реестр увеличивается в размерах. Исходя из этого в процессе добавления/удаления новых ключей данные могут находится в разных местах, есть пустоты, увеличивается объем файла, а следовательно и буфера, выделенного для его кэширования. Так как размер одной страницы составляет 4Кбайт, а для запущенной программы нужна не одна ветвь нужно их несколько, а они лежат в разных частях реестра и каждая имеет хоть какой то объем в байтах, а в ПК у нас запущенно много служб и много программ то если все это перемножить то можно представить сколько байт нужно отвести для кэширования реестра.
У самой Microsoft есть упоминания :
«…Повреждение файлов системного реестра может вызывать появление различных сообщений об ошибках. Сведения об ошибках, связанных с проблемами в системном реестре, см. в соответствующих статьях базы знаний Майкрософт. …»

Есть множество программ которые осуществляют очистку реестра исправляя структурные дефекты и удаляя неверные ссылки. Так например известная программа Auslogics Registry Defrag может так же дефрагментировать и сжимать реестр Windows. Программа фактически переписывает реестр заново, ликвидируя пустые блоки данных и исправляя структурные дефекты, получая компактный и хорошо организованный реестр, который потребляет меньше системных ресурсов и требует меньше времени для обработки запросов приложений и операционной системы.


На данном рисунке загрузка ПК.

Чисткой пользуюсь раз в месяц.

#196445 Бэлиан :
Со временем, большое количество ошибочных параметров реестра может приводить к сбоям и различным проблемам, мешая нормальному функционированию ОС.

На мой взгля, утверждение довольно-таки надуманное. Обосновать можете?

Исходя из этого в процессе добавления/удаления новых ключей данные могут находится в разных местах, есть пустоты, увеличивается объем файла, а следовательно и буфера, выделенного для его кэширования.

Не вполне корректное утверждение. Последней ОС, которая считывала реестр в память целиком, была Windows 2000.

Так как размер одной страницы составляет 4Кбайт, а для запущенной программы нужна не одна ветвь нужно их несколько, а они лежат в разных частях реестра и каждая имеет хоть какой то объем в байтах, а в ПК у нас запущенно много служб и много программ то если все это перемножить то можно представить сколько байт нужно отвести для кэширования реестра.

Непонятно, какое отношение к реестру имеет размер страниц. Представить можно, но сложно, в любом случае - меньше размера реестра.

Есть множество программ которые осуществляют очистку реестра исправляя структурные дефекты и удаляя неверные ссылки.

Правильная формулировка такова: есть множество программ, авторы которых заявляют, что... (далее по тексту).

Чисткой пользуюсь раз в месяц.

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

#196445 Бэлиан :
Так например известная программа Auslogics Registry Defrag может так же дефрагментировать и сжимать реестр Windows. Программа фактически переписывает реестр заново, ликвидируя пустые блоки данных и исправляя структурные дефекты, получая компактный и хорошо организованный реестр, который потребляет меньше системных ресурсов и требует меньше времени для обработки запросов приложений и операционной системы.

Однако величину этих выигрышей никто не хочет огласить вслух. Стесняются, наверное.

Игорь Лейко,
А как вы думаете можно оценить выигрыш от этой манипуляции (дефрагментации реестра) при установке и запуске программ отслеживать все обращения к реестру с секундомером.

Суть данного действия - это привести в порядок информацию расположенную в файлах реестра и избавить его от ненужной.

Понятное для меня описание реестра я нашел в данной книги.

М.Руссинович, Д.Соломон
Внутреннее устройство Windows Server 2003, XP, 2000
Глава 4
Механизмы управления
Реестр стр.196
...
Анализ и устранение проблем с реестром.
Поскольку система и приложение сильно зависят от конфигурационных параметров изменение данных в реестре может вызвать их сбои. Когда системе или программе не удается считать параметры, которые как предполагается всегда доступны, это программное обеспечение может рухнуть и при этом выводить сообщения об ошибках, скрывающих корень проблем. Не понимая, как сбоящая система или программа обращается к реестру, практически не возможно выяснить, какие разделы или параметры реестра сконфигурированы не правильно.
...

Вот несколько выдержек, хотя полное понимание дает только вся глава но все же.




Так же некоторое понятие можно подчеркнуть из статьи http://www.insidepro.com/kk/371/371r.shtml

Книжка хорошая, не спорю, но часть Ваших выводов взята отнюдь не из нее либо, судя по последней цитате, вызвана, к сожалению, недопониманием.

Выигрыш от "оптимизации реестра" ни оценить, ни измерить, на мой взгляд, не удастся, и это делает заявления о пользе программ довольно сомнительными с практической точки зрения.

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

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

Игорь Лейко,
Выигрыш от "оптимизации реестра" ни оценить, ни измерить, на мой взгляд, не удастся, и это делает заявления о пользе программ довольно сомнительными с практической точки зрения.

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

Во всех версиях Windows присутствует ограничение на лимит/размеры кустов, особенно это важно при загрузке, когда диспетчер памяти должен отвести определенное кол-во Мбайт для загрузки кустов (происходит проецирование файлов реестра на системную память) а загрузить нужно именно те кусты которые нужны в данный момент. Теперь если взять размеры файлов например system - 12Mb (куста - HKEY_LOCAL_MACHINE\System), software - 34Mb (куста - HKEY_LOCAL_MACHINE\Software) ну и конечно файл профиля пользователя ntuser.dat - 5Mb (у других пользователей данные значения могут быть ну очень большими). Вот например на другом ПК system - 60Mb (куста - HKEY_LOCAL_MACHINE\System), software - 46Mb (куста - HKEY_LOCAL_MACHINE\Software) ну и конечно файл профиля пользователя ntuser.dat - 5Mb. Раз все это проецируется в память, а лежит на диске то следовательно это все сравнимо с доступом к файлам со всеми последствиями, и добавлю что в файловой системе есть такое понятие как кластер который кратен 4КБ, так и для реестра есть понятие размер блока который равен 4096байт (4КБ). Чтоб не углубляться в тонкости, то реестр можно представить как структура файла на жестком диске (цепочка кластеров), только когда удаляется куст физически из реестра он не удаляется а помечается как удаленный, в результате имеем непонятно что как ячейки имеющие данные, так и пустые так и удаленные и диспетчер при загрузке не будет разбираться относится данный куст к этой программе или нет, тем более что части данного куста могут быть разбросаны по разным местам. В самой Windows предусмотрен механизм "уплотнения" - резервное копирование и потом восстановления (winbackup) вопрос зачем тогда они это придумали, может просто надо было переписать файлы и все.

Игорь Лейко,
К статьям Криса я бы рекомендовал подходить скептически, он отнюдь не стремится к строгости изложения, скорее наоборот.

Но тем не менее она почти так же описывает работу реестра как и в книге.

#196490 Бэлиан :
Игорь Лейко,
Еще раз подчеркну я не веду речь о выигрыше в скорости от дефрагментации реестра, вопрос в надежности работы системы, привести к минимуму кол-во сбоев в работе. Данную структуру можно сравнить с базой данных в которой существует свой формат представления данных, а как всякая база данных требует к себе серьезного отношения и оптимизации, как любой программист который пишет алгоритм работы с базой старается его с оптимизировать.

Естественно, разработчики этой базы (не данных в базе, а самой базы), стараются работу с ней оптимизировать. И поскольку это именно база, то надежность работы системы абсолютно никак не зависит от того, что записано в тех параметрах, к которым система не обращается. Сами по себе данные в базе тоже не портятся (от времени, например), так что насчет сбоев из-за базы как таковой можно не беспокоиться.

Игорь Лейко,
Выигрыш от "оптимизации реестра" ни оценить, ни измерить, на мой взгляд, не удастся, и это делает заявления о пользе программ довольно сомнительными с практической точки зрения.

т.е. что по вашему не видно то сомнительно.

Естественно. А как иначе? Если чего-то не видно и увидеть нельзя, то оно обязательно есть? ;)

Для меня достаточно того, что после дефрагментации он будет упорядочен

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

а после чистки весь хлам от туда будет удален

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

Во всех версиях Windows присутствует ограничение на лимит/размеры кустов, особенно это важно при загрузке, когда диспетчер памяти должен отвести определенное кол-во Мбайт для загрузки кустов (происходит проецирование файлов реестра на системную память)

Вы бы уж уточнили, что проецируется реестр не во всех системах. ;)

а загрузить нужно именно те кусты которые нужны в данный момент.

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

Теперь если взять размеры файлов например system - 12Mb (куста - HKEY_LOCAL_MACHINE\System), software - 34Mb (куста - HKEY_LOCAL_MACHINE\Software) ну и конечно файл профиля пользователя ntuser.dat - 5Mb (у других пользователей данные значения могут быть ну очень большими). Вот например на другом ПК system - 60Mb (куста - HKEY_LOCAL_MACHINE\System), software - 46Mb (куста - HKEY_LOCAL_MACHINE\Software) ну и конечно файл профиля пользователя ntuser.dat - 5Mb. Раз все это проецируется в память, а лежит на диске то следовательно это все сравнимо с доступом к файлам со всеми последствиями

Не совсем так, незадействованные участки реестра в память проецируются, но считаны не будут.

и добавлю что в файловой системе есть такое понятие как кластер который кратен 4КБ

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

Чтоб не углубляться в тонкости, то реестр можно представить как структура файла на жестком диске (цепочка кластеров)

Абсолютно неверно, реестр структура не цепочечная, а древовидная.

только когда удаляется куст физически из реестра он не удаляется а помечается как удаленный

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

Игорь Лейко,
К статьям Криса я бы рекомендовал подходить скептически, он отнюдь не стремится к строгости изложения, скорее наоборот.

Но тем не менее она почти так же описывает работу реестра как и в книге.

Иногда небольшим смещением акцентов можно существенно исказить смысл. Ну и благоглупости в его статьях никто не отменял, например: "К тому же, реестр грузится в RAM-кэш и с ростом фрагментации падает не только производительность, но и увеличивается объем потребляемой памяти!"

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

Речь идет не о сбое базы как таковой а о получении неверных параметров приложением из нее, неоднократно бывали такие случаи:
Приложение работает со сбоями, данное приложение как положено удаляется с ПК методом стандартным как удаление приложения, потом происходит установка заново данного приложения, запускаем приложение оно так же работает со сбоем. Чистим реестр находится куча переменных помеченных как invalid path - я называю это путь в никуда. Повторяем процедуру установки приложения, потом запуск и приложение работает нормально. Это только частный случай.

Может портится все что работает, а именно если есть запись.

Естественно. А как иначе? Если чего-то не видно и увидеть нельзя, то оно обязательно есть?

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

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

Если учесть цитата из книги
М.Руссинович, Д.Соломон
Внутреннее устройство Windows Server 2003, XP, 2000
Глава 4
Механизмы управления
Реестр стр.196

Поэтому если вам нужно найти, скажем ячейку раздела А, родительским разделом которого является раздел B, вы должны с начало найти ячейку со списком подразделов раздела В по ее индексу в ячейке раздела В. После этого с помощью списка индексов из ячейки списка подразделов раздела В можно отыскать ячейки любых подразделов раздела В. При этом для каждой ячейки подраздела вы проверяете, не совпадает ли хранящаяся там имя раздела с именем искомого в данном случае А.

структура была выше

Но если хотя бы несколько циклов такого поиска будет опущено, то следовательно и выигрыш будет.

Как вы считаете, если в графике который ниже, загрузка ПК где с 0 сек. по 70 бурная работа с реестром счетчик аж зашкаливает к 100 000 если уменьшить кол-во обращений или если данные расположены как надо по порядку, следовательно выборка и поиск нужных данных в кусте идет быстрее - загрузка ПК будет быстрее.

ни один разработчик чистилок не может достоверно знать про все записи, является ли та или иная запись хламом или нужной для работы. Про часть записей он может, конечно, получить информацию, но далеко не про все.

Мне достаточно 40-50% найденного.

Само сабой, что читаются они не по одиночки, если кусты в памяти, то они не загружаются еще раз, но если их нет то они будут загружены. Но куст System считывается весь в память.

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

только помеченные как удаленные, пустые и активные загрузятся.

Размер блока реестра равен 4096байт, куст состоит из разделов, а размер куста всегда кратен размеру блока. Для адресации к кустам есть служебная информация, которая так же равна размеру блока.

Абсолютно неверно, реестр структура не цепочечная, а древовидная.

согласен, речь вел о сравнении с дефрагментацией как у файловой системы, например аааа.ааа...ааа.....ааааа

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

Из всего что мне известно на сегодня, данная процедура мне не только греет душу, но и не трачу время на устранение проблем которых не возникает.

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

#196501 Бэлиан :
Не знаю конечно но мы отклонились от темы Дефрагментация реестра. Наши рассуждения думаю пользователям будут не интересны.

Как скажете. ;) А Руссиновича и Соломона все-таки перечитайте еще раз, причем лучше пятое издание.
В четвертом английском одно из искомых мест - на стр. 660-661 (кэш диспетчера виртуальной памяти). В русской книжке страницу не скажу, за ней далеко на полку лезть, а вот ПДФка,

Игорь Лейко,
Просмотрел пятое издание, про реестр.
Имеем куст System, который грузится на начальном этапе в физ.память, размер может быть выделен у 32Bit до 400Мбайт, на 64Bit до 1,5ГБайт. Остальные кусты в виртуальной, интересный будет кус Software, так все приложения держат свои параметры в данном кусте и запросов к ним очень много (см.скрин выше).

Далее переводить не буду, чтоб не нарушить смысл слов при переводе оригинала:

By using bins, instead of cells, to track active parts of the registry, Windows minimizes some management chores. For example, the system usually allocates and deallocates bins less frequently than it does cells, which lets the configuration manager manage memory more efficiently. When the configuration manager reads a registry hive into memory, it reads the whole hive, including empty bins, but it can choose to discard them later. When the system adds and deletes cells in a
hive, the hive can contain empty bins interspersed with active bins. This situation is similar to disk fragmentation, which occurs when the system creates and deletes files on the disk. When a bin becomes empty, the configuration manager joins to the empty bin any adjacent empty bins to form as large a contiguous empty bin as possible. The configuration manager also joins adjacent deleted cells to form larger free cells. (The configuration manager shrinks a hive only when bins at the end
of the hive become free. You can compact the registry by backing it up and restoring it using the Windows RegSaveKey and RegReplaceKey functions, which are used by the Windows Backup utility.)
...
When an application creates a new registry key, the configuration manager first finds the key cell for the new key’s parent. The configuration manager then searches the list of free cells for the hive in which the new key will reside to determine whether cells exist that are large enough to hold the new key cell. If there aren’t any free cells large enough, the configuration manager allocates a new bin and uses it for the cell, placing any space at the end of the bin on the free cell list. The new key cell fills with pertinent information—including the key’s name—and the configuration manager adds the key cell to the subkey list of the parent key’s subkey-list cell. Finally, the system stores the cell index of the parent cell in the new subkey’s key
cell.
The configuration manager uses a key control block’s reference count to determine when to delete the key control block. When all the handles that refer to a key in a key control block close, the reference count becomes 0, which denotes that the key control block is no longer necessary. If an application that calls an API to delete the key sets the delete flag, the configuration manager can delete the associated key from the key’s hive because it knows that no application is keeping
the key open.
...
Cell Maps
The configuration manager doesn’t access a hive’s image on disk every time a registry access occurs. Instead, the configuration manager maps portions of a hive into memory as it needs to access them. It uses the cache manager’s file mapping functions to map 16-KB views into the hive files. (See Chapter 10 for more information on the cache manager.) To prevent hive mapping from consuming all the cache manager’s address range, the configuration manager tries to keep no more than 256 views of a hive mapped at any given point in time by unmapping least-recently-used (LRU) views when it reaches that limit. The configuration manager still uses the paged pool to store various data structures (including the LRU list of views).
Note The configuration manager will store a block in the paged pool instead of mapping it if the block exceeds 256 KB in size.
If hives never grew, the configuration manager could perform all its registry management on the in-memory version of a hive as if the hive were a file. Given a cell index, the configuration manager could calculate the location in memory of a cell simply by adding the cell index, which is a hive file offset, to the base of the in-memory hive image. Early in the system boot, this process is exactly what Winload does with the SYSTEM hive: Winload reads the entire SYSTEM hive into memory as a read-only hive and adds the cell indexes to the base of the inmemory hive image to locate cells. Unfortunately, hives grow as they take on new keys and values, which means the system must allocate paged pool memory to store the new bins that contain added keys and values.
Thus, the paged pool that keeps the registry data in memory isn’t necessarily contiguous.
...

Поэтому для себя решил, пусть мне греет душу - чистка реестра и его дефрагментация, за полгода проблем не возникло.

Не надо мне цитировать целые страницы из книжки, она у меня есть. ;)
По поводу того, сколько реестра грузится в память при старте системы, см. стр. 250.
А на выделенное курсивом могу ответить так: если что-то можно сделать, то это отнюдь не означает, что делать нужно. ;)
Но, конечно, своей системе Вы сами хозяин, не спорю.

Игорь Лейко,

Не надо мне цитировать целые страницы из книжки, она у меня есть.
По поводу того, сколько реестра грузится в память при старте системы, см. стр. 250.

Я рад за вас.
Читать чуть - чуть умею, реестр состоит из кустов и один из них куст System, грузится на начальном этапе в физ.память когда любой другой просто нет.

А на выделенное курсивом могу ответить так: если что-то можно сделать, то это отнюдь не означает, что делать нужно.

Тем не менее скажу например есть такое ПО как Uniblue RegistryBooster которая получила Microsoft Gold Sertified Partner тут есть и чистка реестра и его дефрагментация, я думаю при написании данной программы было использовано такое кол-во материала по данной теме и это не простая прихоть.

http://www.uniblue.com/software/registrybooster/

#196538 Бэлиан :
и это не простая прихоть.

Конечно, это обыкновенное желание отностительно честным путем заработать на слой икорки поверх маслица.
А чтобы стать золотым партнером, достаточно продавать в год программ "Майкрософт" на энную сумму. И все.
Статус присваивается компании и не имеет никакого отношения к продуктам, которые эта компания выпускает.
P.S. Еще ни разу не слышал, чтобы кто-то из разработчиков Windows положительно отозвался о чистильщиках реестра (а вот обратное верно). Тот Regclean, который когда-то они написали (на энтузиазме) не удалял никаких записей, кроме логически поврежденных, и то его перестали дописывать и поддерживать. По причине практической ненужности.