| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
А что на этом канале сидит? dmesg|grep ata? |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
slavutichИз моего опыта - да, собьется. Как оно по правильному должно быть - не знаю. По идее провидение чипсета после того как дежурка пропала и снова появилась зависит от того как это себе придумал вендор. Самый простой способ - проверить на опыте (только питание сбросить на продолжительное время - две-пять минут, или щелкнуть кнопкой включения, ибо кондеры). |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
nafanja, red, вы немножко не в ту сторону уехали. Вопрос не в том, как научить сетевуху будить систему, а как отправить эту самую систему в правильный power state из S5 не каждая машина проснется по wol или таймеру. Тут все зависит от настроек чипсета, поэтому и посоветовал автору глянуть в BIOS. Если кто знает как заставить линукс выключать машину в нужный режим питания, поделитесь. Я обычно не мудрствовал лукаво и вырубал в S4 через systemctl hibernate - на всем, что под руку попадалось, работало. |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
Альтернативный вариант. Просыпается из S4 (Hibernation). Возможно у вас в биос неправильно настроен power state в который надо выключатся (у меня кажется по таймеру просыпалось из SoftOFF). |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
Уже есть для кэша в памяти велосипед. |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
mityukovМне помогло |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
jim945Да, но второй путь это научить систему обрабатывать ситуацию "память кончилась". А третьего пути НЕТ. И еще раз: вы память выделяете не вручную, этим занимается ядро и в вашем случае оно более чем щедро. Приложения рассчитывают на ту память, которую получили. В вашем конкретном случае вы выдаете приложениям память, которой нет и взять негде. Ядро, чтобы не помереть, пытается сгладить ситуацию с помощью операций идентичных сваппингу, но более медленных. Т.е. даже с выключенным свапом у вас свап есть, но медленный и не надежный. Чем лучше отсутствующий свап, свапа которым не пользуются? В первом случае система начнет шуршать винтом пытаясь найти 10Мб физ. памяти в худшем случае помрет, во втором начнет скидывать страницы на диск. Неужели 2Гб на диске жалко? |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
midnight_walkerIMHO не стоит заворачиваться. Самое первое и самое важное - у jim945 все не летает на 1Гб, а как он сам признался, жутко лагает. Из за того, что система, когда ей нужна память использует страницы в которых находится не выполняемый в данный момент код. А если еще он захочет попользовать, например psd для ускорения броузера - его ждет жуткое разочарование. 800М в вашем случае - это норма. Меньше [, а самое главное - быстрее] не сделаете. Можно побаловаться извращениями. Но лучше сходить в магазин и прикупить памяти, а к ней в добавок SSD - разницу увидите невооруженным глазом. На самом деле стоит переживать не из-за того, что система использует целых 65% доступной памяти на вашей типичной задаче, а о том, что она не использует 100% - отзывчивость была бы большей. Но современные линуксы стремятся к этому. Приложения резервируют память "с запасом" - чем больше у вас свободной памяти, тем больше приложения ее потребляют (это можно проследить в постах выше). И да, в вашем конкретном случае корни зла это chromium, skype и dropbox. Замените их на что-нибудь более легковесное, и будет вам счастье. Но не каждый поменяет chromium на links. |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
jim945А кстати откуда ненависть к свапу? Это медленно, происходит потому что код в свап не ходит - ему сделано mmap. Т.е. это система так себя ведет на последнем издыхании - там где код сейчас не выполняется - происходит замещение страницы, а когда код снова нужен, то читается библиотека с диска. Тот-же свап, но вид сбоку и головке по диску дольше скакать - ибо никто /usr/lib и /usr/bin под такое извращение не оптимизирует. Но ситуация ваша очень нестабильна, ибо памяти выделено больше чем есть физически. И вот когда приложение обратиться к области которую оно видит, но которой нет - тогда ядру надо будет слить ненужную страницу на диск и дать ее физическую область процессу. А сливать некуда. Вот тогда и загорится. P.S. А если разделы ужимать не хочется, то кажется можно свап в файл поселить. P.P.S. Если уж совсем не хочется свапов, то я бы на вашем месте ограничил память FF через cgroups. Пусть помирает за прожорливость, хоть система останется стабильной. А можно в группу впихать вообще все пользовательские приложения - получите отзывчивый пользовательский интерфейс и приложения вылетающие за прожорливость. Нехорошая эта ситуация, когда дают то чего нет. P.P.P.S. У вас кстати, скорее всего, выделена половина (512М) оперативки под /tmp. Вот этому делу в свап сливаться сам доктор прописал. |
| naszar |
|
|
Темы:
21
Сообщения:
507
Участник с: 24 сентября 2012
|
Хм.. лучше бы конечно под это отдельную тему.jim945Не уверен, но помоему память, та что VIRT, это то что процессу как-бы выделили, но к которой он не разу не обращался. Кажись может загореться. Интересно, что будет? |