Comments 119
Судя по внешнему виду скрин сделан с 10ки.
Отсюда делаю вывод, что для скриншота пожалели SSD:
обратите внимание это тот самый SSD и кнопочка «анализ» недоступна.
PS на всякий всё равно отключил.
Отсюда делаю вывод, что для скриншота пожалели SSD:
обратите внимание это тот самый SSD и кнопочка «анализ» недоступна.
PS на всякий всё равно отключил.
В голову сразу приходит отключение задания ScheduledDefrag или автоматического обслуживания, но это решение неэффективно. В первом случае вы блокируете запланированную отправку команд TRIM и дефраг жестких дисков, если таковые имеются, а во втором — выполнение других задач обслуживания.
грамотное решение проблемы
Update: для тех, кто не хочет читать обширные ветки комментариев ниже: альтернативное решение проблемы — отключить создание точек восстановления системы и соответствующую службу. Если вы это сделаете, ваш SSD не будет дефрагментироваться.
Разве точки восстановления не могут быть полезны? (в случае сбоев)
Если у меня винда и мрёт, то мрёт капитально из-за моих экспериментов над ней :) Тут точками не отделаешься. А вирусов у меня со времён Conficker-a не было (тогда трафик был ещё платный, по 5 рублей за мегабайт, обновления, естественно, не ставились, а из локалки лезла всякая гадость). Своевременные обновления, запуск подозрительных штук в песочнице и виртуалках…
Отсутствие точки восстановление ударит сильнее, чем траты на неё. У меня на десятке пришлось использовать восстановление после кривого обновления дров Nvidia, на что ушло пара минут. Без точек восстановления времени ушло бы намного позже. Вообще при обновлениях и установках программ точки восстановления самый простой способ гарантировать безопасность, чтобы они не помогли уже придется постараться.
ни разу не доводилось пользоваться точкой восстановления, баг всплывает когда слишком поздно и точка потеряна, а фигня с загрузкой решается миниоткатом реестра, к последней удачной загрузке. если случилось что-то совсем адское то надо уже бэкап разворачивать а не точку.
Ну обычно баги связанные с обновлением и установкой программ и драйверов видны сразу. В любом случае обычным пользователям точки откаты полезны, затраты на них достаточно низки, а пользу они приносят. Это самое простое средство восстановления системы, и при его отключении надо его чем-то заменить, и это что-то настроить.
с помощью команды «Win + R» — «dfrgui» — «Изменить параметры» — и далее отключаем «плановое обслуживание» для нашего SSD
Тем самым, вы ухудшили работу своего диска, отключив вместе с дефрагментацией подачу команды TRIM. У приличного числа моделей после этого со временем производительность ощутимо просядет. Натвикают ОС, а потом ругаются, что «десяточка тормозит, в XP такого не было».
Правильное решение в ветке комментариев выше.
Вы сейчас о древних SSD или о новых и почти новых?
Обо всех, это зависит от контроллера. Некоторые контроллеры почти не теряют производительность без TRIM, в обзорах иногда это указывается, поскольку полезно для пользователей WinXP (она не умеет без сторонних утилит) и параноиков (при создании зашифрованного раздела рекомендуется отключить TRIM, иначе злоумышленник может узнать, какие блоки пусты, а чем меньше он знает, тем лучше для нас).
А что мешает контроллеру самостоятельно себя приводить в порядок? И какие объемы данных, о которых что-то там ОС может сообщить путем подачи TRIM (и о чем со стороны контроллера догадаться нельзя)?
Отсутствие знаний о том, нужна информация вон в том блоке файловой системе, или это остатки удалённых файлов. Файловая система ведь не перезаписывает нулями удалённые файлы, а лишь помечает для себя, что вон там свободное место. А контроллер этого не знает, пока ему не сообщат.
Проще говоря, TRIM позволяет контроллеру сразу узнавать, какие блоки свободны и заранее, во время простоя, планировать, производить нужные операции по оптимизации и перемещению данных. В противном случае, он узнаёт об этом в самый последний момент, когда подана команда записать данные в свободное (с точки зрения ОС) пространство, в результате чего, будет необходимые операции спешно производить прямо перед этой записью. А для пользователя и ОС это выглядит, как замедление записи.
Проще говоря, от того, что контроллер узнает об этом позже (когда на это место будут что-то записывать), ему хуже не станет в «нормальных условиях». Он запишет новые данные в блок, не требующий трима, а позже затримит грязные блоки.
Т.е. я все еще не вижу, от чего ему должно поплохеть. Чтобы ему поплохело, нужно чтобы почти все свободное место было нетримленым. А я себе не представляю как этого добиться в бытовых условиях.
Т.е. я все еще не вижу, от чего ему должно поплохеть. Чтобы ему поплохело, нужно чтобы почти все свободное место было нетримленым. А я себе не представляю как этого добиться в бытовых условиях.
UFO just landed and posted this here
Вот из вики, например: "… Применение TRIM позволяет устройству SSD уменьшить влияние сборки мусора, которая в противном случае в дальнейшем выразится падением производительности операций записи в затронутые секторы..." и сноска на некий «Shimpi, Anand Lal. (2009-03-18). p. 10.» без ссылки. Фраза витиеватая и попахивает старинными былинами. Сколько на практике надо ждать (под семеркой и с бюджетным SSD на Физоне) этого «в дальнейшем»?
Ждать пока не заполнятся записью все свободные сектора. Но некоторые ssd сами во время простоя занимаются сборкой мусора.
В цело мне понимаю зачем отключать файл подкачки на ssd? На сколько он уменьшит срок службы?
В цело мне понимаю зачем отключать файл подкачки на ssd? На сколько он уменьшит срок службы?
UFO just landed and posted this here
>> Ждать пока не заполнятся записью все свободные сектора.
Так и помереть можно.
Объем «помеченного как удаленное, но не перезаписанного» пространства не разрастается до масштабов всего диска. Винда имеет обыкновение затыкать дырки подходящими файлами. Обновления, кеш браузера, темпы, логи. Откуда возьмется нетримленное пространство в угрожающих количествах?
Это разве что на 120-гиговый SSD залить две игры по 50 гиг и удалить их. Если есть желание на такие эксперименты… У меня — нет )) А так, за пол года ничего эдакого не дождался.
P.S.: А файл подкачки при чем? О нем не было речи
Так и помереть можно.
Объем «помеченного как удаленное, но не перезаписанного» пространства не разрастается до масштабов всего диска. Винда имеет обыкновение затыкать дырки подходящими файлами. Обновления, кеш браузера, темпы, логи. Откуда возьмется нетримленное пространство в угрожающих количествах?
Это разве что на 120-гиговый SSD залить две игры по 50 гиг и удалить их. Если есть желание на такие эксперименты… У меня — нет )) А так, за пол года ничего эдакого не дождался.
P.S.: А файл подкачки при чем? О нем не было речи
>Винда имеет обыкновение затыкать дырки подходящими файлами. Обновления, кеш браузера, темпы, логи. Откуда возьмется нетримленное пространство в угрожающих количествах?
Винда не имеет доступа до физического расположения данных на ssd. Там полная власть у контроллера.
Если в прошивке не реализовали фоновую чистку диска (на старых такого помнится и не было), то постепенно забьются все свободные ячейки, а потом контроллер перед записью будет делать стирание, что скажется на скорости. А винда и ПО найдет как заполнить свободное место. Логи, кеши, сам контроллер может решить перенести чатсь информации…
Винда не имеет доступа до физического расположения данных на ssd. Там полная власть у контроллера.
Если в прошивке не реализовали фоновую чистку диска (на старых такого помнится и не было), то постепенно забьются все свободные ячейки, а потом контроллер перед записью будет делать стирание, что скажется на скорости. А винда и ПО найдет как заполнить свободное место. Логи, кеши, сам контроллер может решить перенести чатсь информации…
«помеченное как удаленное» — это разговор о логическом уровне, который неизвестен контроллеру
«ОС не управляет физическим расположением» — это разговор о физическом уровне
Факт того, что на физическом уровне грязные блоки могут соваться куда угодно (распределяться равномерно), никак не определяет того, в каком количестве будет этого не перезаписанного барахла. Количество определяется как раз алгоритмами ОС и поведением пользователя. Т.е. спускаться на физический уровень здесь не нужно.
«ОС не управляет физическим расположением» — это разговор о физическом уровне
Факт того, что на физическом уровне грязные блоки могут соваться куда угодно (распределяться равномерно), никак не определяет того, в каком количестве будет этого не перезаписанного барахла. Количество определяется как раз алгоритмами ОС и поведением пользователя. Т.е. спускаться на физический уровень здесь не нужно.
Количество будет стремиться к полному заполнению. Быстрее или медленнее, но все свободные ячейки без уборки мусора будут использованы.
Так уборка мусора у подавляющего большинства нынешних контроллеров — есть.
А ветка началась с устаревшего warning-а:
«Тем самым, вы ухудшили работу своего диска, отключив вместе с дефрагментацией подачу команды TRIM. У приличного числа моделей после этого со временем производительность ощутимо просядет.»
Вот это было актуально где-то когда-то. И то — поди знай, был ли смысл обращать внимание на этот переполох. Один выяснил, что «дефрагментация на SSD не дефражит, а TRIM посылает», а другой выяснил, что это не всегда так. И пошла серия статей про «выключать или не выключать». Сто лет назад, в пору тормозных Кингстонов, заполонивших все полки магазинов и по сей день не исчезнувших с них.
А кто в курсе, в какой винде и по какому алгоритму (как часто) сейчас в 2016-ом TRIM отправляется? Уверены, что ОС не сообщает об удалении каждый раз при удалении? Кто сказал, что ОС вообще перестает отправлять TRIM, если удалено задание на плановое обслуживание/дефрагментацию? Гугль только старье выдает.
А ветка началась с устаревшего warning-а:
«Тем самым, вы ухудшили работу своего диска, отключив вместе с дефрагментацией подачу команды TRIM. У приличного числа моделей после этого со временем производительность ощутимо просядет.»
Вот это было актуально где-то когда-то. И то — поди знай, был ли смысл обращать внимание на этот переполох. Один выяснил, что «дефрагментация на SSD не дефражит, а TRIM посылает», а другой выяснил, что это не всегда так. И пошла серия статей про «выключать или не выключать». Сто лет назад, в пору тормозных Кингстонов, заполонивших все полки магазинов и по сей день не исчезнувших с них.
А кто в курсе, в какой винде и по какому алгоритму (как часто) сейчас в 2016-ом TRIM отправляется? Уверены, что ОС не сообщает об удалении каждый раз при удалении? Кто сказал, что ОС вообще перестает отправлять TRIM, если удалено задание на плановое обслуживание/дефрагментацию? Гугль только старье выдает.
Вот это было актуально где-то когда-то. И то — поди знай, был ли смысл обращать внимание на этот переполох. Один выяснил, что «дефрагментация на SSD не дефражит, а TRIM посылает», а другой выяснил, что это не всегда так. И пошла серия статей про «выключать или не выключать»
Если вы прочитаете серию статей, посвящённую проблеме дефрагментации SSD, то доберётесь до итога: сотрудник Microsoft Скотт Хансельман посоветовался с коллегами и выяснил, что дефрагментация производится, если включено создание точек восстановления системы.
Любой диск проработавший некоторое время будет заполнен на 100% данными.
Вы удалили файл — но на диске он остался.
Поэтому для диска в принципе нормально быть заполненному на 100%.
Для SSD это неприемлемо, ибо усложняет и замедляет запись, поэтому приходится использовать TRIM.
Можно работать и без TRIM — оставьте побольше неразмеченного места, и TRIM будет не нужен.
Вы удалили файл — но на диске он остался.
Поэтому для диска в принципе нормально быть заполненному на 100%.
Для SSD это неприемлемо, ибо усложняет и замедляет запись, поэтому приходится использовать TRIM.
Можно работать и без TRIM — оставьте побольше неразмеченного места, и TRIM будет не нужен.
Неразмеченная область нужна чтобы оставить место для работы сборщика мусора, если до упора диск не забивать то и неразмеченная область не нужна.
Без использования TRIM после более-менее продолжительной работы c точки зрения контроллера диск будет всегда стремится к 100% заполнению, даже если с точки зрения ОС на нем еще скажем 50% свободного места. Все кластеры / сектора в которые хоть однажды было что-то записано с точки зрения контролера уже заняты, даже если на уровне ОС и пользователя соответствующие файлы давно удалены и кластеры значатся как свободное неиспользуемое пространство.
И? контроллеру до лампочки на разметку диска, он знать не знает про устройство файловой системы. Независимо от вашей разметки он будет писать в свободные ячейки пока не использует их все и без разницы находятся они в размеченной области или нет.
Все не использует если только за раз очень много записать без пауз — не давая провести оптимизацию, потому при наличии не размеченной области в которую ОС никогда не писала в логической таблице (которую контроллер тоже ведет) соответствующий объем будет всегда оставаться свободным не зависимо как она проецируется на физические блоки флеша. И даже в таком случае(если все быстро забить записью так, что контроллер использует все свободные блоки для ускорения записи) как только появится «свободная минутка» контроллер обратно освободит ее физически и она будет готова для записи без циклов считали-модифицировали-стерли-записали обратно, а просто «записали».
Без неразмеченной области и при неработающем TRIM ( Jump об этом случае говорил) свободной области через какое-то время работе не будет вообще — с точки зрения контроллера все сектора будут постоянно заняты, хотя с точки зрения ОС еще полно свободного места. И даже во время «сбора мусора» контроллер ничего сделать не может — именно потому, что он ничего не знает про файловую систему и если он хоть раз получал команду записать что-то в определенный сектор, он будет считать его занятым. В результате запись будет возможна только через модификацию блоков(считали/модифицировали/стерли/записали), что сильно снижает скорость и ускоряет износ.
Без неразмеченной области и при неработающем TRIM ( Jump об этом случае говорил) свободной области через какое-то время работе не будет вообще — с точки зрения контроллера все сектора будут постоянно заняты, хотя с точки зрения ОС еще полно свободного места. И даже во время «сбора мусора» контроллер ничего сделать не может — именно потому, что он ничего не знает про файловую систему и если он хоть раз получал команду записать что-то в определенный сектор, он будет считать его занятым. В результате запись будет возможна только через модификацию блоков(считали/модифицировали/стерли/записали), что сильно снижает скорость и ускоряет износ.
Спасибо за подробное объяснение, но ведь практически у всех дисков есть несколько процентов невидимых для ОС блоков.
Да, обычно производитель об этом заранее подумал зная все эти факторы и "спрятал" от пользователя небольшой % емкости, чтобы свободные блоки были всегда, даже если пользователь разметит весь диск и потом его забьет под завязку (или не забъет, но будет использовать на системе с неработающим TRIM, что через какое-то время с точки зрения контроллера станет эквивалентом полностью забитого диска).
Так сказать подстраховка на худший случай/вариант использования.
Некоторые резервируют поменьше — обычно на разницу между двоичными и десятичными приставками (ГиБ и ГБ). Другие (ориентируясь на большую скорость и живучесть в ущерб емкости) делают резерв побольше и из-за этого получаются "не круглые" емкости типа 120 ГБ доступного вместо 128 ГиБ установленного флэша или 240 ГБ вместо 256 ГиБ.
Во 2м случае самостоятельно дополнительно резервировать смысла уже ИМХО не имеет — у производителя и так достаточно большой резерв для работы контроллера оставлен в скрытой области — для 240 Гб диска это к примеру будет почти 13%.
>> Любой диск проработавший некоторое время будет заполнен на 100% данными.
Если речь все еще о логической структуре, то утверждение излишне строгое и размытое. Вот например, за пол года винда еще не нашла причин писать в конец раздела. Не возникает необходимости менять местами пустое и занятое пространство. Только лишь граница между ними двигается туда-сюда незначительно. Практически все файлы, регулярно меняющие свой размер и, как следствие, расположение, не достаточно большие, чтобы провоцировать неумолимое расширение границ занятого пространства. Для этого нужны чуть более особые условия (связанные с гигантскими файлами), нежели типичная работа ОС и офисных приложений.
>> Для SSD это неприемлемо, ибо усложняет и замедляет запись, поэтому приходится использовать TRIM.
Это понятно, а суть всей данной ветки обсуждения в том, что нет однозначного понимания, как TRIM работает. Одни считают, что по всей логике TRIM посылается достаточно часто (я, к примеру, лишь догадывался, что возможно сразу же, но никакой уверенности в этом не было) и никак не может отключиться при выключении еженедельного обслуживания дисков. Другие же считают, что TRIM посылается исключительно (или преимущественно?) раз в неделю и если выключить то задание, то «всё пропало». Причиной этому послужила волна статей 3-4 года назад (которая рассматривая один вопрос ввела в заблуждение по поводу другого) и отсутствие внятной четкой информации по TRIM (много написано зачем он, но мало — как он действует).
Если речь все еще о логической структуре, то утверждение излишне строгое и размытое. Вот например, за пол года винда еще не нашла причин писать в конец раздела. Не возникает необходимости менять местами пустое и занятое пространство. Только лишь граница между ними двигается туда-сюда незначительно. Практически все файлы, регулярно меняющие свой размер и, как следствие, расположение, не достаточно большие, чтобы провоцировать неумолимое расширение границ занятого пространства. Для этого нужны чуть более особые условия (связанные с гигантскими файлами), нежели типичная работа ОС и офисных приложений.
>> Для SSD это неприемлемо, ибо усложняет и замедляет запись, поэтому приходится использовать TRIM.
Это понятно, а суть всей данной ветки обсуждения в том, что нет однозначного понимания, как TRIM работает. Одни считают, что по всей логике TRIM посылается достаточно часто (я, к примеру, лишь догадывался, что возможно сразу же, но никакой уверенности в этом не было) и никак не может отключиться при выключении еженедельного обслуживания дисков. Другие же считают, что TRIM посылается исключительно (или преимущественно?) раз в неделю и если выключить то задание, то «всё пропало». Причиной этому послужила волна статей 3-4 года назад (которая рассматривая один вопрос ввела в заблуждение по поводу другого) и отсутствие внятной четкой информации по TRIM (много написано зачем он, но мало — как он действует).
Не некоторые SSD занимаются сборкой мусора, а абсолютно все.
Т.е любой SSD с определенной периодичностью выполняет сборку мусора, как правило делается это в моменты неактивности диска.
Т.е любой SSD с определенной периодичностью выполняет сборку мусора, как правило делается это в моменты неактивности диска.
Есть SSD в которых не выявлено следов присутствия сборщиков мусора, так что с «абсолютно все» вы погорячились.
Не все. Помню тесты, ssd. Заполнялся под крышку данными, стирали и давали ему время на уборку мусора (несколько часов). Не все ssd смогли/захотели делать уборку мусора. В результате падение скорости записи.
Сборщик мусора — это программа которая стирает неиспользуемые блоки, и следит за равномерным износом ячеек.
Если сборщика мусора нет — значит диск не сможет удалить данные, только записать.
Падение скорости возникает тогда, когда сборщику мусора приходится работать во время активного использования диска.
Если сборщика мусора нет — значит диск не сможет удалить данные, только записать.
Падение скорости возникает тогда, когда сборщику мусора приходится работать во время активного использования диска.
После заполнения диска и без очистки любая процедура записи будет включать в себя предварительные операции, что замедлит скорость на любых по активности операциях записи.
Вот сценарий работы с и без TRIM. Phison — это целая линейка контроллеров, говорить о каком-то абстрактном «физоне в вакууме» сложно.
Из этого тестирования, например, следует, что у PS3110-S10 без TRIM дела идут не лучшим образом.
Из этого тестирования, например, следует, что у PS3110-S10 без TRIM дела идут не лучшим образом.
У них и с 850 Pro — беда. Дескать, не выполняет сборку совсем. А Samsung утверждает, что выполняет.
Кстати, резонный вопрос, который следовало задать изначально, но в пылу обсуждения как-то замялось. С чего вы вообще взяли, что выключение периодического обслуживания означает жизнь «без TRIM»?
Вот у меня в семерке вся самодеятельность отключена. Службы дефрагментации выключена. Задания в планировщике в большинстве своем удалены. Трим работает, судя по trimcheck-0.7-win64 и по отсутствию деградации.
Вот у меня в семерке вся самодеятельность отключена. Службы дефрагментации выключена. Задания в планировщике в большинстве своем удалены. Трим работает, судя по trimcheck-0.7-win64 и по отсутствию деградации.
С чего вы вообще взяли, что выключение периодического обслуживания означает жизнь «без TRIM»?
Периодическое обслуживание (оптимизация) представляет собой команду
defrag /o /u /v <буква диска>/O Начиная с Windows 8, выполняет оптимизацию в зависимости от типа накопителя: жесткие диски дефрагментирует, а твердотельным повторно отправляет набор команд TRIM.
Это понятно. Но как по-вашему, что означает слово «повторно» в последнем предложении? И следует ли из приведенной цитаты то, что при отключении этого периодического задания «вы ухудшили работу своего диска»?
Я понимаю это как «при каждом выполнении оптимизации посылается набор команд TRIM». Оптимизация выполняется примерно раз в неделю. Причём, этот период очень хорошо совпадает с рекомендациями Intel, которая в фирменной утилите по обслуживанию своих твердотельных накопителей советует посылать TRIM раз в неделю.
Отключая задание, мы отключаем вместе с дефрагментацией и отсылку TRIM. А она тем полезней, чем меньше свободного пространства. Так что, да, отключая задание и ничего не предлагая диску взамен, мы ухудшаем его работу.
Отключая задание, мы отключаем вместе с дефрагментацией и отсылку TRIM. А она тем полезней, чем меньше свободного пространства. Так что, да, отключая задание и ничего не предлагая диску взамен, мы ухудшаем его работу.
>> Я понимаю это как «при каждом выполнении оптимизации посылается набор команд TRIM».
… ПОВТОРНО отправляет набор команд TRIM.
Почему вы игнорируете это слово?
==============
>> Отключая задание, мы отключаем отсылку TRIM.
Домысел, не подтвержденный приведенной цитатой. Именно вокруг него и весь сыр-бор.
=============
>> Intel, которая в фирменной утилите по обслуживанию своих твердотельных накопителей советует посылать TRIM раз в неделю.
Intel советует установить и юзать Intel SSD Toolbox, при этом отключить дефрагментацию и SuperFetch (зачем-то):
http://www.intel.com/content/www/us/en/support/software/000006462.html
При этом уточняется, что начиная с семерки команда TRIM активирована по умолчанию. Но не сказано, что ее нужно вручную или заданием раз в неделю выполнять. Это всего-лишь уведомление об удалении файлов. Его можно слать как угодно часто. Что винда и делает, судя по всему. Без вашего вмешательства и вопреки отключению еженедельной дефрагментации, которая что-то там шлет ПОВТОРНО.
… ПОВТОРНО отправляет набор команд TRIM.
Почему вы игнорируете это слово?
==============
>> Отключая задание, мы отключаем отсылку TRIM.
Домысел, не подтвержденный приведенной цитатой. Именно вокруг него и весь сыр-бор.
=============
>> Intel, которая в фирменной утилите по обслуживанию своих твердотельных накопителей советует посылать TRIM раз в неделю.
Intel советует установить и юзать Intel SSD Toolbox, при этом отключить дефрагментацию и SuperFetch (зачем-то):
http://www.intel.com/content/www/us/en/support/software/000006462.html
При этом уточняется, что начиная с семерки команда TRIM активирована по умолчанию. Но не сказано, что ее нужно вручную или заданием раз в неделю выполнять. Это всего-лишь уведомление об удалении файлов. Его можно слать как угодно часто. Что винда и делает, судя по всему. Без вашего вмешательства и вопреки отключению еженедельной дефрагментации, которая что-то там шлет ПОВТОРНО.
Окей, если уж придираться, то слово «повторно» оттуда же, откуда и «Отключая задание, мы отключаем отсылку TRIM.» — от автора блога, ссылку на который я уже в N-ный раз приводить не буду. В справке по defrag кроме «оптимизации с учётом типа накопителя» ничего не сказано.
Интеловский софт, очень вероятно, сам отправляет команду TRIM. Поэтому связка «отключение дефрагментации + интеловский софт» полностью эквивалентна связке «отключение дефрагментации + слать вручную или заданием».
Можно, но это совершенно ненужная нагрузка на контроллер. Всё равно что руки мыть каждый час. Или установить срок аренды IP-адреса равным 5 минутам. У нас админ провайдера так сделал. Каждые 5 минут клиентам прилетали айпишники (они были привязан к MAC-адресам, поэтому не менялись) и адреса DNS-серверов. Вреда, вроде, никакого, но и смысла тоже. Когда я спросил «а зачем?», меня поблагодарили за обращение и поставили срок равным 12 часам (скорее всего, ставили «5 минут» пока что-то тестировали или настраивали, да убрать забыли). Так и тут. Зачем флудить контроллер (TRIM) или сервер (DHCP) запросами, если никакой существенной разницы между «очень часто» и «не так часто» нет?
Судя по чему?
Но не сказано, что ее нужно вручную или заданием раз в неделю выполнять.
Интеловский софт, очень вероятно, сам отправляет команду TRIM. Поэтому связка «отключение дефрагментации + интеловский софт» полностью эквивалентна связке «отключение дефрагментации + слать вручную или заданием».
Его можно слать как угодно часто
Можно, но это совершенно ненужная нагрузка на контроллер. Всё равно что руки мыть каждый час. Или установить срок аренды IP-адреса равным 5 минутам. У нас админ провайдера так сделал. Каждые 5 минут клиентам прилетали айпишники (они были привязан к MAC-адресам, поэтому не менялись) и адреса DNS-серверов. Вреда, вроде, никакого, но и смысла тоже. Когда я спросил «а зачем?», меня поблагодарили за обращение и поставили срок равным 12 часам (скорее всего, ставили «5 минут» пока что-то тестировали или настраивали, да убрать забыли). Так и тут. Зачем флудить контроллер (TRIM) или сервер (DHCP) запросами, если никакой существенной разницы между «очень часто» и «не так часто» нет?
Что винда и делает, судя по всему. Без вашего вмешательства и вопреки удалению еженедельной дефрагментации.
Судя по чему?
Судя по trimcheck-0.7-win64
>> Можно, но это совершенно ненужная нагрузка на контроллер.
Владение актуальной и полезной информацией — ненужная нагрузка? Тем более, учитывая объем работ, который может совершить ваше скучающее железо за доли секунды.
>> Можно, но это совершенно ненужная нагрузка на контроллер.
Владение актуальной и полезной информацией — ненужная нагрузка? Тем более, учитывая объем работ, который может совершить ваше скучающее железо за доли секунды.
Судя по trimcheck-0.7-win64
Запущенной в Windows 7? Всё, что я писал в этом треде относится к Windows не ниже 8.
Периодически узнавать текущее время тоже нужно, но если вам будут каждую секунду постоянно докладывать о текущем времени, вы малость перегрузитесь и скажете «да нафига оно мне, мне и каждый час нормально».
Сбор мусора накопитель начинает не через доли секунды простоя. Пруфов не будет, но в тестах я видел упоминание того, что он выжидает существенно дольше.
Подобьём итоги для тех, кто будет нас читать в будущем:
— В Windows XP TRIM не отправляется операционной системой.
— Windows 7 через четыре года превратится в тыкву, поэтому копать глубоко, как там устроена дефрагментация (ключа /o = оптимизации с учётом типа накопителя, там ещё не было), желающих не нашлось.
— В Windows 8.1 дефрагментация SSD осуществляется, если не выключено создание точек восстановления И файлы сильно фрагментированы. Источник: сотрудники Microsoft.
— По Windows 10 данных нет, но, поскольку, нет оснований полагать, что поведение изменилось, разумно полагать, что оно не изменилось (если что-то работает, то программисты его и не трогают).
— TRIM полезна, и тем полезнее, чем меньше свободного места осталось на диске.
Вывод: проще всего в Windows 8+ ничего не трогать. Никакого существенного вреда не будет. Но если хочется, то можно отключить оптимизацию SSD и создать задание в планировщике. Вреда тоже не будет, но, возможно, будет мизерная польза. А может и её не будет и всё это послужит лишь для удовлетворения желания «потюнинговать систему».
В общем-то, я не вижу о чём тут ещё спорить благородным донам.
— В Windows XP TRIM не отправляется операционной системой.
— Windows 7 через четыре года превратится в тыкву, поэтому копать глубоко, как там устроена дефрагментация (ключа /o = оптимизации с учётом типа накопителя, там ещё не было), желающих не нашлось.
— В Windows 8.1 дефрагментация SSD осуществляется, если не выключено создание точек восстановления И файлы сильно фрагментированы. Источник: сотрудники Microsoft.
— По Windows 10 данных нет, но, поскольку, нет оснований полагать, что поведение изменилось, разумно полагать, что оно не изменилось (если что-то работает, то программисты его и не трогают).
— TRIM полезна, и тем полезнее, чем меньше свободного места осталось на диске.
Вывод: проще всего в Windows 8+ ничего не трогать. Никакого существенного вреда не будет. Но если хочется, то можно отключить оптимизацию SSD и создать задание в планировщике. Вреда тоже не будет, но, возможно, будет мизерная польза. А может и её не будет и всё это послужит лишь для удовлетворения желания «потюнинговать систему».
В общем-то, я не вижу о чём тут ещё спорить благородным донам.
Да при чем тут вообще дефрагментация?! Отстаньте от нее!
Выключение еженедельной дефрагментации не отключает никакой TRIM. Это было бы верхом идиотизма.
Выключение еженедельной дефрагментации не отключает никакой TRIM. Это было бы верхом идиотизма.
TRIM это уведомление об удалении файлов, посылается непосредственно при удалении файлов.
В некоторых случаях когда например вы сжимаете файл бд — отправки уведомления бывает не происходит.
Поэтому ее полезно иногда отправлять и вручную или из планировщика, что собственно и сделано она отправляется при оптимизации диска.
По поводу дефрагментации — я бы не рекомендовал отключать дефрагментацию, зачем вам фрагментированная ФС?
От дефрагментации раз в месяц ничего диску не будет, перемещаемый объем данных очень маленький.
В некоторых случаях когда например вы сжимаете файл бд — отправки уведомления бывает не происходит.
Поэтому ее полезно иногда отправлять и вручную или из планировщика, что собственно и сделано она отправляется при оптимизации диска.
По поводу дефрагментации — я бы не рекомендовал отключать дефрагментацию, зачем вам фрагментированная ФС?
От дефрагментации раз в месяц ничего диску не будет, перемещаемый объем данных очень маленький.
Лично я ее отключаю потому, что пользуюсь для дефрагментации vopt-ом и вручную. В этом есть практический смысл для тех, кто хочет знать, что у них под капотом творится.
Заглядываю с частотой, которая мне удобна. Когда удобно. С интересом рассматриваю карты разделов, прежде чем запускать дефрагментацию.
Во-первых, убеждаюсь, что раздел-хранилище крайне редко и мало фрагментируется, если не накидывать в него файлов, скачиваемых через браузеры (которые почему-то по сей день не «заказывают» размер файла при создании).
Во-вторых, могу дефрагментировать «по-виндовому» (без уплотнения, лишь устраняя фрагментацию), могу с уплотнением.
В-третьих, вижу на сколько много каши образуется обычно на системном разделе. В случае если ее оказалось излишне много — что-то не так. Или если задумал вынести кеш браузера на рам-диск — позже смог оценить визуально его вклад в фрагментацию (увидел на сколько меньше стало каши).
В четвертых, сейчас, в условиях, когда нет смысла дефражить SSD, любопытно проследить, на сколько системному разделу удастся фрагментироваться, скажем, за год. Относительно любопытно, т.к. я не сторонник частых переустановок всего ПО и мелкого ежедневного апдейта системы, так что в моем случае не сильно любопытно следить за медленным и не достаточно масштабным загаживанием мало меняющейся системы.
В пятых, да мало ли по какой еще причине пользователь не желает пользоваться коробочным инструментом?
Заглядываю с частотой, которая мне удобна. Когда удобно. С интересом рассматриваю карты разделов, прежде чем запускать дефрагментацию.
Во-первых, убеждаюсь, что раздел-хранилище крайне редко и мало фрагментируется, если не накидывать в него файлов, скачиваемых через браузеры (которые почему-то по сей день не «заказывают» размер файла при создании).
Во-вторых, могу дефрагментировать «по-виндовому» (без уплотнения, лишь устраняя фрагментацию), могу с уплотнением.
В-третьих, вижу на сколько много каши образуется обычно на системном разделе. В случае если ее оказалось излишне много — что-то не так. Или если задумал вынести кеш браузера на рам-диск — позже смог оценить визуально его вклад в фрагментацию (увидел на сколько меньше стало каши).
В четвертых, сейчас, в условиях, когда нет смысла дефражить SSD, любопытно проследить, на сколько системному разделу удастся фрагментироваться, скажем, за год. Относительно любопытно, т.к. я не сторонник частых переустановок всего ПО и мелкого ежедневного апдейта системы, так что в моем случае не сильно любопытно следить за медленным и не достаточно масштабным загаживанием мало меняющейся системы.
В пятых, да мало ли по какой еще причине пользователь не желает пользоваться коробочным инструментом?
а зачем она дефрагментированная?, для ссд чтение всегда рандомное блоками по 512к, если элементарно пользоваться корзиной а не удалять всё через шифт делейт то даже за пару лет использования фрагментация не дойдёт до 20% если считать как виндовс — за фрагменты считать блок размером менее 64 мб, тогда как для ссд фрагментация начинается когда блок меньше 512к
А здесь кое-что проясняется:
http://www.intel.com/support/ssdc/hpssd/sb/CS-031221.htm
Answer 7: Intel recommends running Intel SSD Optimizer once per week. (т.к. их оптимизатор выступает вместо отключенного задания винды)
Answer 10: Microsoft Windows* 7 + Microsoft* AHCI = отсутствие необходимости танцев с бубном:
«Trim supported as part of the native operating system (Intel SSD Toolbox with Intel SSD Optimizer not required to run Trim, but nice to have to confirm that Trim has run on the SSD)
А для XP — нужен их оптимизатор. ПРичем, он не только раз в неделю будет трим посылать, он будет делать это по мере возможности (будучи запущенным в фоне и мониторя удаления).
http://www.intel.com/support/ssdc/hpssd/sb/CS-031221.htm
Answer 7: Intel recommends running Intel SSD Optimizer once per week. (т.к. их оптимизатор выступает вместо отключенного задания винды)
Answer 10: Microsoft Windows* 7 + Microsoft* AHCI = отсутствие необходимости танцев с бубном:
«Trim supported as part of the native operating system (Intel SSD Toolbox with Intel SSD Optimizer not required to run Trim, but nice to have to confirm that Trim has run on the SSD)
А для XP — нужен их оптимизатор. ПРичем, он не только раз в неделю будет трим посылать, он будет делать это по мере возможности (будучи запущенным в фоне и мониторя удаления).
Видимо, Интел полагает, что вреда в 8/10 от иногда возможной дефрагментации SSD нет. Microsoft тоже так полагает (раз они это реализовали). Я, в принципе, согласен, что это пустяк, который на ресурс диска, вероятно, не повлияет хоть сколько-то заметно, но забабацать задание в планировщик — это минутное дело, а хуже не станет.
А Windows 7? По-идее она TRIM поддерживает, но я вот сейчас открыл настройки дефрагментатора — как GUI так и консоль, сравнил с тем что в статье и в советах по ссылке выше и пришел к выводу что дефрагментатор семерки вообще не различает жесткие диски от SSD и TRIM не умеет в принципе — тип накопителя не указывается и не определяется, опций выполнить TRIM отдельно от дефрагментации нет, ну и целом все называется именно «дефрагментарией», а не «оптимизацией».
Команды TRIM сразу при удалении файлов подаются? И как бы вообще проверить работает ли реально TRIM в ОС, кроме как сравнениями производительности SSD и сравнения с «эталоном»?
Команды TRIM сразу при удалении файлов подаются? И как бы вообще проверить работает ли реально TRIM в ОС, кроме как сравнениями производительности SSD и сравнения с «эталоном»?
А Windows 7?
Windows 7 должна поддерживать. Но оптимизации с учётом типа диска в ней ещё не было. В целом, я бы рекомендовал использовать ОС поновее, поскольку старые системы проектировались без учёта новых технологий. Да и через 4 года к Windows 7 перестанут выходить обновления.
Команды TRIM сразу при удалении файлов подаются?
Отличный вопрос, мы тут как раз выше яростно по этому поводу спорили. Вендоры рекомендуют раз в неделю подавать. Интересно было бы узнать, как часто подаёт ядро Linux, благо там хоть исходники открыты, в отличие от Windows.
И как бы вообще проверить работает ли реально TRIM в ОС
https://github.com/CyberShadow/trimcheck
Спасибо на ссылочку.
Проверил — TRIM в 7ке (x64) на NTFS томах работает исправно сразу по удаления каждого файла.
При перезапуске программки сразу — находит данные из только что созданного и уже стертого файла.
А вот если секунд 10 хотя бы подождать не дергая диск — в секторах куда был записан удаленный файл уже только нули.
Команда fsutil behavior set disabledeletenotify 0|1 успешно включает/выключает TRIM.
Поэтому провел еще один тест. Отключил TRIM. Удалил созданный файл. Включил TRIM обратно. Тут уже данные остаются на месте и активный TRIM их не подчищает. Ни через некоторое время, ни после перезагрузки — данные из стертого файла по прежнему физически все еще хранятся на диске в тех же самых секторах.
Видимо для этого в Win 8 и позже и включили TRIM как элемент периодического обслуживания диска — чтобы передать контроллеру информацию о всех имеющихся свободных секторах, независимо от того как/когда они освободились. Например чтобы чистить мусор от файлов удаленных в то время, когда по какой-то причине TRIM не был активен и вероятно для программ работающих с прямым доступом к диску минуя файловую систему.
Проверил — TRIM в 7ке (x64) на NTFS томах работает исправно сразу по удаления каждого файла.
При перезапуске программки сразу — находит данные из только что созданного и уже стертого файла.
А вот если секунд 10 хотя бы подождать не дергая диск — в секторах куда был записан удаленный файл уже только нули.
Команда fsutil behavior set disabledeletenotify 0|1 успешно включает/выключает TRIM.
Поэтому провел еще один тест. Отключил TRIM. Удалил созданный файл. Включил TRIM обратно. Тут уже данные остаются на месте и активный TRIM их не подчищает. Ни через некоторое время, ни после перезагрузки — данные из стертого файла по прежнему физически все еще хранятся на диске в тех же самых секторах.
Видимо для этого в Win 8 и позже и включили TRIM как элемент периодического обслуживания диска — чтобы передать контроллеру информацию о всех имеющихся свободных секторах, независимо от того как/когда они освободились. Например чтобы чистить мусор от файлов удаленных в то время, когда по какой-то причине TRIM не был активен и вероятно для программ работающих с прямым доступом к диску минуя файловую систему.
Как-то странно. Получается, что одна и та же команда отрабатывает по-разному. В первом случае информирует об удалённых недавно файлах, но не информирует об удалённых во время отключения подачи команды. А во втором случае (еженедельно) информирует обо всех удалённых.
Возможно, свою роль тут играет и контроллер. Если он узнаёт, что вон в тех блоках хранится удалённый файл, он ведь не обязан моментально бросаться заполнять их нулями или записывать туда содержимое других блоков. Когда он решит, что пора бы блоки перетасовать для оптимального размещения, тогда и перетасует. А когда именно он решит — зависит от алгоритмов прошивки.
Возможно, свою роль тут играет и контроллер. Если он узнаёт, что вон в тех блоках хранится удалённый файл, он ведь не обязан моментально бросаться заполнять их нулями или записывать туда содержимое других блоков. Когда он решит, что пора бы блоки перетасовать для оптимального размещения, тогда и перетасует. А когда именно он решит — зависит от алгоритмов прошивки.
Одинаково отрабатывает. Это поведение ОС (в данном конкретном примере Win 7) разное.
От прошивки конечно зависит, но конкретно для своего я проверил — как только ОС ему сообщила что какие-то сектора свободны, он в ближайшее же время (через несколько секунд неактивности) начинает их физически удалять/очищать.
Насколько помню TRIM передает контроллеру лишь диапазон секторов, который ОС считает свободными. При этом только от ОС зависит когда их подавать. Видимо при удалении файла Win7 сразу же после записи в таблицу файлов файловой системы о том, что какие-то кластеры которые занимал файл теперь свободны, одновременно подает и команду TRIM контроллеру в которой сообщает аналогичных диапазон(или несколько диапазонов если файл был фрагментирован) секторов который был(и) заняты этим файлом, чтобы тот мог приступить к очистке без задержек.
Если в момент удаления файла TRIM был отключен(со стороны ОС или со стороны диска) — команда не подается, соответственно контроллер не знает о том, что сектора освободились. А какого-то лога/кэша, чтобы сообщить об этом позже (когда TRIM станет доступен) у винды нет.
Тогда как при дефрагментации/оптимизации выполняемой по расписанию, винда смотрит уже не на удаленные файлы, а просто составляет полный список всех свободных кластеров в файловой системе для всего диска целиком, преобразует их в соответствующие адреса уже секторов (LBA) и кормит контроллеру как длиннющий список команд TRIM в котором перечисляет все незадействованные для хранения каких-либо файлов сектора подряд. Вероятно включая те, про которые контроллер уже и так знает что они свободны — например о которых ОС уже сообщала при удалении файлов. Хуже от этого не будет, т.к. это же не команда заставляющая принудительно их обнулить, а лишь информирование контроллера о том, что данные в этих секторах больше не нужны. Так что если он их уже затирал раньше и они уже и так числятся свободными, то заново он эту работу делать не будет, а обнулит только те о которых еще не было известно что они свободны. Ну при адекватной прошивке по крайней мере.
В общем получается такая глобальная «сверка часов» (синхронизация) между ОС и контроллером, после которой ОС и контроллер имеют идентичную БД о том какие сектора свободны, а какие заняты независимо от всей предыдущей истории работы с диском (может он вообще перед этим под управлением другой ОС работал или в другом компе стоял?). И ввели это начиная с Windows 8 совместив с программой дефрагментации и по этому поводу переименовав ее в программу «оптимизации» диска.
По крайней мере в Win7 я только что проверил — дефрагментация тома на SSD НЕ обнуляет сектора приходящиеся на файлы удаленные до дефграментации. Заодно проверил, что Win7 похоже все-таки нормально отличает SSD от HDD (хоть и не пишет об этом нигде пользователю), по крайней мере предыдущая дефрагментация была более полугода назад(и возможно это я ее вручную запускал) и уровень фрагментации уже был больше 20% — т.е. по расписанию винда ее НЕ проводила определив что том находится на SSD и ему это не требуется.
От прошивки конечно зависит, но конкретно для своего я проверил — как только ОС ему сообщила что какие-то сектора свободны, он в ближайшее же время (через несколько секунд неактивности) начинает их физически удалять/очищать.
Насколько помню TRIM передает контроллеру лишь диапазон секторов, который ОС считает свободными. При этом только от ОС зависит когда их подавать. Видимо при удалении файла Win7 сразу же после записи в таблицу файлов файловой системы о том, что какие-то кластеры которые занимал файл теперь свободны, одновременно подает и команду TRIM контроллеру в которой сообщает аналогичных диапазон(или несколько диапазонов если файл был фрагментирован) секторов который был(и) заняты этим файлом, чтобы тот мог приступить к очистке без задержек.
Если в момент удаления файла TRIM был отключен(со стороны ОС или со стороны диска) — команда не подается, соответственно контроллер не знает о том, что сектора освободились. А какого-то лога/кэша, чтобы сообщить об этом позже (когда TRIM станет доступен) у винды нет.
Тогда как при дефрагментации/оптимизации выполняемой по расписанию, винда смотрит уже не на удаленные файлы, а просто составляет полный список всех свободных кластеров в файловой системе для всего диска целиком, преобразует их в соответствующие адреса уже секторов (LBA) и кормит контроллеру как длиннющий список команд TRIM в котором перечисляет все незадействованные для хранения каких-либо файлов сектора подряд. Вероятно включая те, про которые контроллер уже и так знает что они свободны — например о которых ОС уже сообщала при удалении файлов. Хуже от этого не будет, т.к. это же не команда заставляющая принудительно их обнулить, а лишь информирование контроллера о том, что данные в этих секторах больше не нужны. Так что если он их уже затирал раньше и они уже и так числятся свободными, то заново он эту работу делать не будет, а обнулит только те о которых еще не было известно что они свободны. Ну при адекватной прошивке по крайней мере.
В общем получается такая глобальная «сверка часов» (синхронизация) между ОС и контроллером, после которой ОС и контроллер имеют идентичную БД о том какие сектора свободны, а какие заняты независимо от всей предыдущей истории работы с диском (может он вообще перед этим под управлением другой ОС работал или в другом компе стоял?). И ввели это начиная с Windows 8 совместив с программой дефрагментации и по этому поводу переименовав ее в программу «оптимизации» диска.
По крайней мере в Win7 я только что проверил — дефрагментация тома на SSD НЕ обнуляет сектора приходящиеся на файлы удаленные до дефграментации. Заодно проверил, что Win7 похоже все-таки нормально отличает SSD от HDD (хоть и не пишет об этом нигде пользователю), по крайней мере предыдущая дефрагментация была более полугода назад(и возможно это я ее вручную запускал) и уровень фрагментации уже был больше 20% — т.е. по расписанию винда ее НЕ проводила определив что том находится на SSD и ему это не требуется.
«Все модули памяти компании Kingston имеют пожизненную гарантию.» — ну и что может случиться со старой RAM, если плату механически не гнуть, частоту и питание не превышать?
А вот у меня возьми сдохни через 5 лет ddr2 от самсунга.
Может ещё стабилизатор питания ОЗУ на мамке «помог» памяти сдохнуть, т.е. «конденсаторная чума» вызвала скачки напряжения.
По опыту эксплуатации всякого старья типа CPU AMD 5x86-133 + EDO RAM (примерно с 1997 до 2016 года, 40ч в неделю) оперативка в ПК помирает реже всего.
По опыту эксплуатации всякого старья типа CPU AMD 5x86-133 + EDO RAM (примерно с 1997 до 2016 года, 40ч в неделю) оперативка в ПК помирает реже всего.
Это врядли, хотя и не лазил с осциллографом по питальнику, вторая плашечка жива до сих пор, а времени минуло ууу.
Просто «дерьмо случается».
Просто «дерьмо случается».
Пока не было искусств. дерьма (копроэкономики), например BGA технологий с безсвинцовыми припоями, моральное устаревание шло намного быстрее физического.
Ну не знаю, вот если судить по моему опыту ddr1 ddr2 менее надёжны чем dd3, матплаты до появления твердотельных конденсаторов просто расходный материал, бп туда же, 680тая живёт дольше парочки видюх из свинцовой эпохи, хотя да 8*** 5** серии от нвидии много кому запомнились своей выпечкой(а кому то запомнился абит ), флопики откидывались быстрее флэшек. Но, таки да найдя в чьём нибудь шкафу системник с 286 процессором на борту можно удивиться как оно так долго проработало, когда на прошлой неделе мобильник сдох.
«Мэйнстрим» конца прошлого столетия Cyrix 486DX2-50 долго работал под ДОСом на паскале в системе управления станком. Без кулера. 8МБ памяти, 270МБ диск, baby AT «мамка», блок питания только от пыли чистили и вентилятор смазывали.
И странно, что сейчас на ebay этот зелёненький CPU с неразвитым пассивным алюм. радиатором стоит на уровне нового 4-х ядерного проца.
И странно, что сейчас на ebay этот зелёненький CPU с неразвитым пассивным алюм. радиатором стоит на уровне нового 4-х ядерного проца.
-del- (не туда ответил)
старые планки по цене новых… ну наверное где-то такое и есть, дураков везде хватает.
мне всегда казалось, что тот, кто покупает б/у — обычно знает что он делает и зачем. и уж точно не покупает старые планки по цене новых. хотя опять же, дуракам закон не писан =(
мне всегда казалось, что тот, кто покупает б/у — обычно знает что он делает и зачем. и уж точно не покупает старые планки по цене новых. хотя опять же, дуракам закон не писан =(
«В выборе между «два четыре модуля по 8 Гбайт против двух по 16 Гбайт» следует иметь ввиду максимальное количество каналов, которые поддерживает процессор. Если ему по силам только двухканальный режим — есть смысл не забивать свободные слоты модулями меньшего объёма.»
А для каких задач это важно? Там же такой запас, что даже трудно представить, как оно может упереться в потолок у кого-то, кроме видео-редакторов.
А для каких задач это важно? Там же такой запас, что даже трудно представить, как оно может упереться в потолок у кого-то, кроме видео-редакторов.
> Поэтому делайте бэкапы и покупайте правильные, надёжные SSD, господа гики!
Так вы и в прошлый раз говорили про надёжность. Все неприятности, что вы рассказываете про секонд-хенд переносятся и на использование просто старых устройств.
Так вы и в прошлый раз говорили про надёжность. Все неприятности, что вы рассказываете про секонд-хенд переносятся и на использование просто старых устройств.
UFO just landed and posted this here
Примерно так плашки и попадают на барахолку: пятиминутный тест проходят, ночной нет и гордому обладателю брачка приходит в голову слить озу.
UFO just landed and posted this here
У меня одна такая была. Начинала глючить только на втором-третьем проходе мемтеста. ИЧСХ, первые час-полтора после включения ПК все было отлично. а вот потом начинались радости ошибок памяти, неверной адресации и в конце концов BSOD. Проверял на трех ПК, адресное пространство ошибки памяти всегда было +- одним и тем же, т.е. сбоил какой-то чип. Прогрев ничего не дал, поэтому глючную плашку я выбросил, купив взамен у китайцев посвежее. Плашке было около 3 лет, работала по графику 8\5, DDR2.
сталкивался с таким более 3 раз, отдельный случай — битый модуль даже умудрялся проходить все расширенные тесты(каюсь кеширование не отключал)потому что даже на первый круг терпения не хватит), при этом попытка загрузить виндовс приводила к чёрному экрану, а линукс к артефактам на экране, и только спустя неделю модуль начал показывать ошибки. после замены глюки видеокарты также пропали. Это были времена когда подрабатывал выездным ломастером, первым делом всегда делал 2 круга мемтеста если компьютер вообще грузился. и половина случаев глюков и синяков это оперативка.
Пыль, кондёры, вирусы, недоперепатчи MS Win — 95%
оперативка — 0,5%
Или фирму кингстон надо привлечь за недобросовестную рекламу пожизненной гарантии.
https://habrahabr.ru/post/171407/
«ошибки памяти часто лечатся банальной чисткой контактов.»
«раз в год меняем планку памяти по гарантии из нескольких тысяч что стоят у меня в серверах, в основном ДДР3.»
оперативка — 0,5%
Или фирму кингстон надо привлечь за недобросовестную рекламу пожизненной гарантии.
https://habrahabr.ru/post/171407/
«ошибки памяти часто лечатся банальной чисткой контактов.»
«раз в год меняем планку памяти по гарантии из нескольких тысяч что стоят у меня в серверах, в основном ДДР3.»
статистику отказов серверной озу применять к сборкам 4 гига 4 ядра — сильно.
В серверной памяти кроме термодатчиков и контроля чётности ничего принципиально отличного от десктопной нет.
Если эти 4 гига за первые 12 мес. не вернули в магазин по гарантии, то и дальше они будут жить-поживать, баги от космич. лучей наживать :)
Если эти 4 гига за первые 12 мес. не вернули в магазин по гарантии, то и дальше они будут жить-поживать, баги от космич. лучей наживать :)
разница в том что в десктопные сборки берут чё подешевле лишь бы влезть в бюджет, а потом разглядывая вторичные/третичные тайминги берёт тихий ужос. когда вместо привычных 18 видишь 33 вместо 160 200- это вжжж не спроста.
Серверное оборудование может пережиить ошибку памяти во время работы, память там ECC.
UFO just landed and posted this here
Занимался как-то в меру серьезно тестированием памяти. Чипсеты Qxx, мат. платы не сказать, что дешевые, десктопные. Память, соответственно, без ECC. От поставщиков не приходило откровенно битых планок, чтобы memtest после 5 минут теста выдавал ошибку. Но дальше интересно. Довольно часто первая ошибка появлялась после 8-10 полного прохода, это несколько суток тестов при 32 гб памяти. Причем повторный запуск на такое же время часто не давал ошибок. Более того, если комплект из 4 планок дал ошибку, зачастую тестирование по отдельности тоже не давало ошибок.
Вывода я сделал два:
1. Если нужна надежность, то память должна быть с ECC. Кстати, сейчас память с ECC не сильно дороже обычной, но E3 процессоры в большинстве не содержат видео, а видеокарты, встроенные в платы для рабочих станций, как правило никакие.
2. Если память без ECC и откровенно не битая (не дала ошибку на первом проходе), то скорее всего вы никогда не узнаете, что с памятью проблема. Возможно столкнетесь пару раз за год с тем, что браузер или другое приложение выдали ошибку, но вы не будете списывать на проблему с памятью.
Вывода я сделал два:
1. Если нужна надежность, то память должна быть с ECC. Кстати, сейчас память с ECC не сильно дороже обычной, но E3 процессоры в большинстве не содержат видео, а видеокарты, встроенные в платы для рабочих станций, как правило никакие.
2. Если память без ECC и откровенно не битая (не дала ошибку на первом проходе), то скорее всего вы никогда не узнаете, что с памятью проблема. Возможно столкнетесь пару раз за год с тем, что браузер или другое приложение выдали ошибку, но вы не будете списывать на проблему с памятью.
Странно читать такие советы в блоге Kingston Technology.
Зачем отключать файл подкачки?
Файл подкачки должен быть включен, а в случае если у вас SSD, то он должен находится на SSD, иначе зачем тогда вообще SSD нужен?
SuperFetch отключается автоматически на SSD, а если бы он и был включен — ничего вредного он не сделает без запланированного запуска дефрагментации, просто пользы от него не будет.
По поводу дефрагментации — на SSD она автоматически отключается в Windows.
В некоторых случаях, при определенных условиях она все же включается раз в месяц — ничего страшного в этом нет — объем перемещаемых файлов небольшой, и на ресурсе никак не скажется.
Включение дефрагментации обусловлено тонкостями работы NTFS с теневыми копиями — иногда возникает сильная фрагментация файловой системы.
Т.е процесс дефрагментации не имеет смысла для SSD, но вполне нужен для фрагментированной базы данных NTFS…
Зачем отключать файл подкачки?
Файл подкачки должен быть включен, а в случае если у вас SSD, то он должен находится на SSD, иначе зачем тогда вообще SSD нужен?
SuperFetch отключается автоматически на SSD, а если бы он и был включен — ничего вредного он не сделает без запланированного запуска дефрагментации, просто пользы от него не будет.
По поводу дефрагментации — на SSD она автоматически отключается в Windows.
В некоторых случаях, при определенных условиях она все же включается раз в месяц — ничего страшного в этом нет — объем перемещаемых файлов небольшой, и на ресурсе никак не скажется.
Включение дефрагментации обусловлено тонкостями работы NTFS с теневыми копиями — иногда возникает сильная фрагментация файловой системы.
Т.е процесс дефрагментации не имеет смысла для SSD, но вполне нужен для фрагментированной базы данных NTFS…
Зачем отключать файл подкачки? Файл подкачки должен быть включен
А зачем его включать?
За венду не скажу, но под линуксом в случае какой-нибудь утечки памяти при прогоне тестов, например, я предпочту убитый по OOM процесс интерпретатора, чем систему, ушедшую в своп на 10 ГБ и о-о-очень медленно реагирующую на какие-либо действия пользователя. А если у меня не хватает памяти для выполняемых задач, я в первую очередь задумаюсь о том, чтобы увеличить ее объем.
Я где-то читал (поэтому за правдивость не ручаюсь), что некоторые ресурсоёмкие программы (игры, например), могут вести себя непредсказуемо, если разработчик не учёл то, что файл подкачки может быть отключён. Поэтому, рекомедовалось его ограничить минимальным размером, но не уничтожать вовсе.
Ну в данном случае речь именно о Windows, хотя для линукса это в большинстве случаев тоже справедливо.
Если памяти достаточно, то подкачка почти не используется, и уж никак не тормозит работу системы.
2)Если памяти недостаточно без подкачки получим проблемы.
3)Существует такая штука как фрагментация памяти — без свопа память не дефрагментируешь, т.е получаем ситуацию когда у нас из 16Гб памяти свободно 8Гб, а приложению выделить больше 2Гб не получается, ибо она вся раздроблена на мелкие куски.
4)Использование памяти неоптимально, данные которые долго не используются, и без дела торчат в памяти сбрасываются в подкачку — но из памяти не удаляются. Если кому-то срочно потребовалось дать много памяти — удаляем их из памяти и выделяем память тому, кому она действительно необходима, если никому не потребовалась память — а данные у нас по прежнему в памяти и доступ к ним быстрый.
Т.е отключение подкачки это снижение быстродействия компьютера, и возможность поиметь проблем при нехватке памяти.
Бывают редкие исключения, как правило в серверах, когда есть процесс с неограниченным аппетитом пожирающий память и его надо поставить в рамки. Но это именно исключение и проблема, а не нормальная ситуация.
Если памяти достаточно, то подкачка почти не используется, и уж никак не тормозит работу системы.
2)Если памяти недостаточно без подкачки получим проблемы.
3)Существует такая штука как фрагментация памяти — без свопа память не дефрагментируешь, т.е получаем ситуацию когда у нас из 16Гб памяти свободно 8Гб, а приложению выделить больше 2Гб не получается, ибо она вся раздроблена на мелкие куски.
4)Использование памяти неоптимально, данные которые долго не используются, и без дела торчат в памяти сбрасываются в подкачку — но из памяти не удаляются. Если кому-то срочно потребовалось дать много памяти — удаляем их из памяти и выделяем память тому, кому она действительно необходима, если никому не потребовалась память — а данные у нас по прежнему в памяти и доступ к ним быстрый.
Т.е отключение подкачки это снижение быстродействия компьютера, и возможность поиметь проблем при нехватке памяти.
Бывают редкие исключения, как правило в серверах, когда есть процесс с неограниченным аппетитом пожирающий память и его надо поставить в рамки. Но это именно исключение и проблема, а не нормальная ситуация.
есть процесс с неограниченным аппетитом пожирающий память и его надо поставить в рамки. Но это именно исключение и проблема, а не нормальная ситуация.
Конечно это проблема. Но пока я решаю эту проблему, лично мне, как я сказал, удобнее, если этот самый процесс убивается, а не ставит колом всю систему :)
А уж держать своп на серверах… По мне так это как грабли с укороченной ручкой: бьет больно и в совершенно неожиданном месте. Вплоть до невозможности минут эдак двадцать подключиться по ssh, потому что кривой скрипт по обработке логов «съел» памяти сколько смог (и еще чуть-чуть), из-за чего sshd тупо выгружен в своп, а сервер «ушел в себя» и гоняет данные между свопом и озу. И иногда самый быстрый вариант — позвонить на площадку и попросить нажать на ресет. А убился процесс по OOM — ну нехорошо, да. Но он хотя бы перезапустился за адекватное время и снова работает.
Проще говоря, если памяти хватает — проблем нет, если памяти не хватает — проблемы есть и без свопа и со свопом. Приходится выбирать из двух зол. И какое из них меньшее — это еще большой вопрос.
Из собственного опыта: без файла подкачки сыпятся ошибки запуска и работы любого приложения, если оперативная память вся задействована. Операционной системе просто некуда высвобождать память.
Интересно, почему на десктопах ОЗУ портится, для его диагностики даже специальное ПО придумали, а в смартфонах проблемы бывают с чем угодно, только не с ОЗУ? В своей практике, по крайней мере, я с подобным не встречался. Или тоже случается?
Пожалуйста, не пользуйтесь незнакомыми словами!
https://ru.wiktionary.org/wiki/%D0%BF%D1%80%D0%B5%D1%81%D1%82%D0%B0%D0%B2%D0%B8%D1%82%D1%8C%D1%81%D1%8F
https://ru.wiktionary.org/wiki/%D0%BF%D1%80%D0%B5%D1%81%D1%82%D0%B0%D0%B2%D0%B8%D1%82%D1%8C%D1%81%D1%8F
UFO just landed and posted this here
Работа без свопа может быть полезна тем, что проще обнаруживать сильно текущее ПО/драйвера.
Разгадка проста: «старые SSD», скорее всего, на MLC-памяти, а новые — на TLC.
Рынок потребительских SSD сейчас, грубо говоря, поделён на накопители, подключающиеся по SATA и PCI-E. Первые уже давно приблизились к ограничениям интерфейса, поэтому конкуренция пошла «у кого подешевле». А TLC-память дешевле, но менее долговечна. И компенсировать её меньший ресурс можно лишь программно, алгоритмами прошивки контроллера. Что требует квалифицированных инженерных кадров. Возрастает цена ошибки инженеров, благодаря чему мы имеем откровенно провальные и забагованные модели даже у таких монстров, как Самсунг и Плекстор.
Рынок потребительских SSD сейчас, грубо говоря, поделён на накопители, подключающиеся по SATA и PCI-E. Первые уже давно приблизились к ограничениям интерфейса, поэтому конкуренция пошла «у кого подешевле». А TLC-память дешевле, но менее долговечна. И компенсировать её меньший ресурс можно лишь программно, алгоритмами прошивки контроллера. Что требует квалифицированных инженерных кадров. Возрастает цена ошибки инженеров, благодаря чему мы имеем откровенно провальные и забагованные модели даже у таких монстров, как Самсунг и Плекстор.
«два четыре модуля по 8 Гбайт против двух по 16 Гбайт»
Так все-таки два или четыре? Напомнило: www.youtube.com/watch?v=RfXMxQlUmvQ
«Если данные не были зашифрованы бдительным почившим программатором»
Программатором? Или все-таки контроллером?
Так все-таки два или четыре? Напомнило: www.youtube.com/watch?v=RfXMxQlUmvQ
«Если данные не были зашифрованы бдительным почившим программатором»
Программатором? Или все-таки контроллером?
Дефрагментация SSD и так будет отключена системой (Win7, может что-то на следующих и поменялось).
Про память внутренняя жаба говорит мне что имеет смысл брать модули максимальной ёмкости для слота. Т.е. при выборе 2x16 или 4x8 я возьму первый, чтоб потом не гадать кому сплавить 2 модуля по 8. Это не считая что про многоканальность какой-то бред написан.
Про память внутренняя жаба говорит мне что имеет смысл брать модули максимальной ёмкости для слота. Т.е. при выборе 2x16 или 4x8 я возьму первый, чтоб потом не гадать кому сплавить 2 модуля по 8. Это не считая что про многоканальность какой-то бред написан.
Sign up to leave a comment.
Старый друг хуже новых всех, или чем опасны б/у оперативная память и SSD