[quote=zhevak]вот-вот! И я о том же.
Так, еще раз, -- кому это ликбез нужен?
Не ну можно конечно про сиськи, но форум-то про никсы smile[/quote]
+1
Что, в гугл лучше?
PS Только бы тему специальную подобрать/создать
[quote=zhevak]вот-вот! И я о том же.
Так, еще раз, -- кому это ликбез нужен?
Не ну можно конечно про сиськи, но форум-то про никсы smile[/quote]
+1
Что, в гугл лучше?
PS Только бы тему специальную подобрать/создать
[quote=yxma]И круто загнать /тмп в простаивающую память.
глупо.
Смотрите - вы создаёте временный файл в /tmp, и почти сразу его уничтожаете. А теперь внимание, вопрос: неужели Линус и все разработчики ядра настолько тупые, что-бы писать этот файл на диск? Никуда он не пишется, он дальше памяти никуда и не уходит. Так там и остаётся, в "дисковом кеше". И лежит он там до тех пор, пока память полностью не заполнится. Временный файл ядро может записать на диск лишь в том случае, если
1) ядру делать нефиг
и
2) устройство простаивает.
Но если условия выполнены, то юзер не замечает тормозов.
А вы можете дальше заниматься бесполезными "оптимизациями". Желательно на винфаке :)[/quote]
В действительности не все так красиво - если тмп на диске, то и файл будет лежать именно там, например, если я его не почти сразу уничтожил. Файл создается не на "чтобы было круто", а с целью использования. И пока при использовании система читает/пишет эти файлы, 3 из 4 гигов рама тупо отдыхают. Так что пошел качать алигию.
А ведь я так привык к внучке бубунты...
В действительности не все так красиво - если тмп на диске, то и файл будет лежать именно там
Если файл доступен в /tmp или где-то в другом месте, это не значит что он уже на диске, иначе представьте как пришлось бы каждый раз ждать пока файл запишется на диск.
Так что пошел качать алигию.
А ведь я так привык к внучке бубунты...
Зачем? Это все легко настраивается в любом дистре.
просканировать порты, и взломать один из доступных серверных компонентов.
Это противозаконно кстати.
То есть вы пойдете как соучастник, давший заведомо "незаконный" совет? smile
Мы знаем все это одинаково хорошо. Не понимаем друг друга в деталях
не очень важно, сколько именно вмещает байт атомарная операция свопинга. страницу, или слово. Или там линейку кеша. Не важно. Важно то, что это очень маленький кусочек, маленький по сравнению с памятью в 2011ом году.
И очевидно, что при полном заполнении памяти, мы сможем обменивать её лишь атомарными кусочками. Вот если у нас есть свободной скажем 100метров, то можно дать команду DMA-контроллеру, и он сам скинет на диск ненужные 100 мегабайт, и скачает оттуда нужные 100 мб. Почти всегда в памяти есть ненужный кеш, но вот в свопе кеша не бывает (ваш К.О.), вся память в свопе нужная. И там всегда должно быть свободное место. Причём не 4К, а МНОГО. Выделяя своп в 2 размера ОЗУ мы гарантированно выделяем там свободные куски, и ядро туда может ВСЕГДА скинуть сотни и тысячи мегабайт чего-нибудь, что сейчас не нужно, ну например упомянутую фотку в гимпе, которую юзверь вчера открыл. И забыл про неё сегодня. Удалять её нельзя, но и в памяти её держать тоже ненужно.
Да, если у вас всего одна задача, причём ей нужно 1025Мб, причём у вас всего 1024мб (как в описываемом вами случае), то эта задача будет жрать 1024Мб памяти, +1Мб кеша, и соответственно, работать со скорость HDD, т.е. в 100..1000 раз медленнее. Я знаю. У меня тоже часто такое. Однако, на десктопе решаются несколько другие задачи, во первых их много, во вторых, 90% из них можно легко положить в своп, ибо юзер их не видит, а ежели он их захочет увидеть, то задержку в 50мс он нам простит. Подождёт, пока его рюшечка скачается из свопа. Однако, что-бы рюшечка скачалась за 50мс, а не за 5000, необходимо, что-бы
1) было свободное место в памяти для рюшечки.
2) если п1 не выполнен, то место надо освободить, скинув в своп что-то ненужное (другую, невидимую рюшечку)
3) для выполнения п2 необходимо, что-бы в свопе была непрерывная и большая дыра
Ещё в середине прошлого века, Дональд Кнут доказал, что ЛЮБАЯ система распределения памяти будет тупить, если она заполнена почти целиком. Тогда дыры в ней будут меленькими, и новая информация станет сильно фрагментированной. Потому доступ к ней будет долгим. Тот-же Кнут рекомендует, для хранения N байт использовать 2*N байтовое устройство.
Особенно важно наличие свободного места и отсутствие фрагментации в том случае, если объём информации большой, "большой" по сравнению с атомом диска и памяти (4К), и по сравнению с одним цилиндром диска, и по сравнению с кешем диска. Если памяти больше 256М, то её МНОГО, она не влезет ни в какой кеш, и её придётся собирать по поверхности диска. Это ОЧЕНЬ ДОЛГО, если у вас не SSD. Потому важно, что-бы данные в свопе лежали едиными кусками, тогда задержки на свопирование станут незаметными для пользователя. Обычно, для достижения этого достаточно выделить двойной объём RAM.
В действительности не все так красиво - если тмп на диске, то и файл будет лежать именно там
НЕ БУДЕТ
ну кто вам такую глупость-то сказал?! даже если вы смонтируете tmp на флешке, то файл туда не попадёт, а потеряется, если вы эту влешку выдернете. Попробуйте сами. Только загрузите флешку работой, а то ядру будет нечего делать, и оно запишет туда временный файл. Файлы записываются на диск лишь при размонтировании ("безопасное извлечение" в венде). А вот если вы не размонтировали носитель, то данные туда НЕ ОБЯЗАНЫ записываться.
Файл создается не на "чтобы было круто", а с целью использования.
и кто мешает их использовать из дискового кеша? Вы лично?
И пока при использовании система читает/пишет эти файлы, 3 из 4 гигов рама тупо отдыхают. Так что пошел качать алигию.
подождите. сначала померьте скорость создания временного файла "на диске", а потом проверьте, сколько это займёт "в памяти". Я проверил - одинаково.
Я сначала отредактировал большой файл командой sed, а потом отредактировал его повторно. Второй раз редактирование происходило намного быстрее, ибо файл был в памяти(и результат тоже). При этом, красная лампочка HDD продолжала мигать ПОСЛЕ редактирования. Очевидно, ядро писало файл на диск, хотя для команды sed файл УЖЕ был записан.
Если файл доступен в /tmp или где-то в другом месте, это не значит что он уже на диске, иначе представьте как пришлось бы каждый раз ждать пока файл запишется на диск.
угу. можно какой-то параметр сменить, что-бы так оно и было. sync-чё-то там. Не помню.
И тогда придётся каждый раз ждать, пока файл будет записан на диск. Операция сохранения ВНЕЗАПНО начнёт тормозить.
То есть вы пойдете как соучастник, давший заведомо "незаконный" совет?
нет.
я вас как раз и предупреждаю об уголовной ответственности.
Тема как то сама собой заглохла.
Скоро 1 апреля, провайдер даст мне исчо 2гига на закачку. Судя по количеству пакетов в явных фаворитах - минт, дебиан и убунта (по возрастанию).ЕБУНТА - 26000 ПАКЕТОВ - это о чем то говорит. Может кто подскажет какая графическая оболочка лучше? Если есть такая же таблица и для оболочек как и для разных линухов было бы не плохо.
Если есть такая же таблица и для оболочек как и для разных линухов было бы не плохо.
http://en.wikipedia.org/wiki/Comparison_of_X_window_managers
учтите, можно в любой Linux установить любой WM/DE.
Slitaz кто-нибудь пробовал на 256 мегабайт оперативной памяти? Нужен реально лёгкий дистрибутив с хорошим интерфейсом + установил и работай хотя-бы в сети. Столько всего пробовал, но тормозят сильно.
кто-нибудь пробовал на 256 мегабайт оперативной памяти?
1)Нужен реально лёгкий дистрибутив
2)с хорошим интерфейсом
+ установил и работай хотя-бы в сети. Столько всего пробовал, но тормозят сильно.
(1) противоречит (2).
Я ставил Slackware 13 + IceWM - имхо лучше всего. Но таки настроить надо.
botanig, runtu LXDE 10.04 smile на 320 метрах оперативки претЪ
drBatty, ну вот Slitaz посмотри. По скриншотам вроде ничего так.
botanig, зачем мне?
http://linuxforum.ru/viewtopic.php?id=8488
Судя по таблице KDE рулит.
drBatty спасибо. Вроде я определился - УБУНТА и КДЕ - осталось всё собрать с новым ядром (качнул с www.kernel.org - 2.6.38). И на четвертом пне все установить. Надеюсь не сильно будет тормозить.
GAR_kin, будет и очень даже. Там надо кучу ОЗУ (не менее 2-3Гб) и шустрый процессор. Плюс придётся допиливать smile
С Gnome лучше wink
будет и очень даже. Там надо кучу ОЗУ (не менее 2-3Гб) и шустрый процессор. Плюс придётся допиливать smile
С Gnome лучше wink
в слаке не так. гном нормально работает. как и кеды
Gnome везде нормально работает
Wolfenberg, с кучей ОЗУ Вы загнули. Calculate 11.0, KDE 4.5.5 "искаропки", кушает около 700 Мб, половину из которых отжирает Опера с 30 вкладками (зачем так много - это уже другой вопрос) + открыты LibreOffice Writer и Kopete. ЧЯДНТ?
Ranyar, та нет, не загнул. В Kubuntu необходимо хорошее кэширование, если не хотите смотреть на "сверхплавную" работу тормозов системы.
ЯВРЗ? У меня ОЗУ-2Гб. Зачастую их просто едва хватает на работу системы. В результате запросто может сброситься фон рабочего стола, зависнуть тот же Smplayer...
Для сравнения - в мандриве у меня на всё про всё хватало 1Гб оперативки.
Ну Вы блин даёте. Возвращаясь к нашим баранам -так что же тогда ставить на P IV, 2,8ГГц и 1гиг памяти? Так ещё и видео - GF440MX (AGP).
P. S. Где то на просторах видел описание как записать новое ядро на CD, стартовать с него и поставить на машину. На сколько я понял у каждого ЛИНУХА своё ядро, тогда для кого ядра на официальном сайте www.kernel.org ? Или у меня каша в голове.
В борьбе за пользователя победит тот пакет который наиболее стабилен, а рюшечек и красатулечек в WIN7 полно. Так же в ОКОШкАХ - НЕСТАБИЛЬНОСТЬ, ЗАСИЛИЕ ВИРУСОВ, НЕОБХОДИМОСТЬ ПЕРЕСТАВЛЯТЬ ХОТЯ БЫ РАЗ В ГОД.
От Линукса требуется тоже самое, но с точностью на оборот...
GAR_kin, если вам нужны рюшечки, стабильность и быстрота до кучи-ставьте мандриву. Она как раз подходит по параметрам. Или Linux Ubuntu (она так похожа на винду, только панелька сверху wink ).
Ядро вы установите одновременно с дистрибутивом при загрузке с диска.