Где моя память, чувак?

>ничего "жадного" нет: GNOME

это такой тонкий троллинг? :)

> но за две минуты кто-то "украл" 20 мегабайт памяти

Учить матчасть на предмет работы линукса с памятью. Конкретно - изучить buffers и cached.

Это ещё мало, потом вся память займётся. Если стоит 2 гига, должны использоваться все 2 гига, если не программами, то буферами и кэшом, а не простаивать незанятыми.

говорят новые иксы слишком текучи, но всего лишь говорят - можно ли в это верить?

> это такой тонкий троллинг? :)

Нет, толстое развязываение GNOME vs. KDE :)

> Учить матчасть на предмет работы линукса с памятью. Конкретно - изучить buffers и cached. 

Почитаю.

> Это ещё мало, потом вся память займётся. Если стоит 2 гига, должны использоваться все 2 гига, если не программами, то буферами и кэшом, а не простаивать незанятыми.

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

Видимо, тут дело даже не в памяти, а в работе планировщика ввода/вывода. Но как такое может происходить?

eveel{~}% cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq] 
eveel{~}% cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]

> говорят новые иксы слишком текучи, но всего лишь говорят - можно ли
> в это верить?

Даже если это так, то дело вряд ли в иксах. Пусть память кушается, но откуда латентность?

>Среди приложений ничего "жадного" нет: GNOME, Opera, Pidgin. Как убить такой аппетит к ресурсам?

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

htop тебе поможет...

а не фри.. в аштопе нагляднее

> а не фри.. в аштопе нагляднее

От увиденного стало плохо:

2986 eveel     20   0  143M 23060 13948 S  1.0  1.1  0:12.73 gnome-terminal
4660 eveel     20   0  198M  114M 15440 S  0.0  5.7  0:00.53 /usr/lib/opera/9.62/opera
2893 eveel     20   0  137M 28568 18312 S  0.0  1.4  0:53.37 pidgin
6892 eveel     20   0 92124 18764 12344 S  0.0  0.9  0:00.42 transmission
2232 root      20   0  167M 50432 11356 S  2.0  2.4 10:34.26 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-G7SrrX/database -nolisten...

Это нормально?

Несмотря на Mem:2025M used:516M buffers:53M cache:973M (как-то странно htop оценивает память), смотрим вывод free:
             total       used       free     shared    buffers     cached
Mem:       2074184    1584452     489732          0      55056    1000348
-/+ buffers/cache:     529048    1545136
Swap:      2096440          0    2096440

Вопрос про тормоза остаётся в силе.

>>но откуда латентность?

в толксы зайди, поведаю

> в толксы зайди, поведаю

Ну, я про системную латентность, тормозит музыка :)

купи мак, там нет системной латентности

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

>купи мак, там нет системной латентности

Кстати, а как в маке сделана прорисовка интерефейса, видео и прочего? Просто, я замечаю тормоза лишь тогда, когда запускаю какую-нибудь тяжелую игру на своём макбуке; В остальных же случаях, пусть хоть какая программа пытается кушать всё - интерфейс и видео остаются на нормальном уровне.

В убунте же такой ужас, когда видно, как прорисовывается каждый элемент, всё безбожно тормозит, но(! главное) операции архивирования, обработки больших файлов, игр (в полноэкранном) идут на хорошем уровне, вполне опережая мак, где хватает процессора или видеокарты. Видео, однако, не в приоритете.

Вопрос: в чём разница вывода изображения в убунте (метасити, гном) и макоси? И как сделать так же, перевести приоритет в интерфейс?

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

Может, pulseaudio? За ним такие грешки водились, судя по отзывам.

Опера кушает подозрительно много (если открыто 30-40 вкладок, то ссзб).
А вот Пиджин похоже течет как весенние ручьи. Прибей его и посмотри что будет.

> Опера кушает подозрительно много (если открыто 30-40 вкладок, то ссзб).

Две (2) вкладки. Правда используется не opera из репозитария tigro, а вручную установленная из: ftp://ftp.opera.com/pub/opera/linux/962/final/en/i386/opera-9.62.gcc4-qt4.i38...

> А вот Пиджин похоже течет как весенние ручьи. Прибей его и посмотри что будет.

Попробую. А для gnome-terminal и Xorg такое потребление - вполне нормально?

> Может, pulseaudio? За ним такие грешки водились, судя по отзывам.

Наверняка он.

Вспомнил, была заявлена фича http://fedoraproject.org/wiki/Features/GlitchFreeAudio : rewrite the PulseAudio sound server to use timer-based audio scheduling.

Очевидно, причина может быть в этом самом таймере, сейчас почитаю, попробую и отпишусь.

Включи сортировку по памяти что-ли: htop ==> F6 ==> Mem

У меня:

free -m
             total       used       free     shared    buffers     cached
Mem:          2026       1603        423          0        101       1183
-/+ buffers/cache:        318       1708
Swap:          980          0        980

Ничего не глючит, окна прорисовываются моментально, амарок не заикается (работает через альсу). 

Gnome + e16 @ C2D 2.3

Короче: попробуй заменить metacity на что-то вменяемое (openbox, E), поставь альсу вместо пульса, и не юзай пиджин.

После следования совету: http://fedoraproject.org/wiki/Features/GlitchFreeAudio#Contingency_Plan , звук перестал "дёргаться", всем большое спасибо за советы.

> Короче: попробуй заменить metacity на что-то вменяемое (openbox, E), поставь альсу вместо пульса, и не юзай пиджин.

Вообще-то, metacity как раз ведёт себя вполне адекватно: кушает всего 25 мегабайт.

Альсу вместо пульса не поставлю, это несколько нарушит целостность системы и создаст проблемы в будущем.

А что юзать, если не pidgin? Мне нужен мультипротокольный (вернее, icq и jabber) IM-клиент.

Вот часть вывода htop, с сортировкой по VIRT:

  PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 2695 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:02.51 /usr/bin/liferea-
 2712 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:00.00 /usr/bin/liferea-
 2777 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:00.00 /usr/bin/liferea-
 2778 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:00.14 /usr/bin/liferea-
 2795 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:00.00 /usr/bin/liferea-
 2810 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:00.04 /usr/bin/liferea-
 2811 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:00.00 /usr/bin/liferea-
 2812 eveel     20   0  209M 34892 21104 S  0.0  1.7  0:00.00 /usr/bin/liferea-
 3038 eveel     20   0  196M 95164 15508 S  0.0  4.6  2:54.28 /usr/lib/opera/9.
 3046 eveel     20   0  196M 95164 15508 S  0.0  4.6  0:01.95 /usr/lib/opera/9.
 3048 eveel     20   0  196M 95164 15508 S  0.0  4.6  0:00.00 /usr/lib/opera/9.
 3049 eveel     20   0  196M 95164 15508 S  0.0  4.6  0:00.00 /usr/lib/opera/9.
 2250 root      20   0  173M 57568 11312 S  8.0  2.8  3:34.50 /usr/bin/Xorg :0
 3252 eveel     20   0  137M 20844 13948 S  5.0  1.0  0:02.64 gnome-terminal

При сортировке по MEM%, вверх вылезает opera.

eveel{~}% free -m
             total       used       free     shared    buffers     cached
Mem:          2025       1844        181          0         59       1271
-/+ buffers/cache:        513       1512
Swap:         2047          0       2047

В общем-то не так критично: пока система не начнёт свопиться и тормозить, не буду особо заморачиваться.

>Две (2) вкладки.
Мда, я давно не использовал Оперу. Открыл с тремя вкладками - ушло 112М. Значение близкое, так что, думаю, нормально.

>А для gnome-terminal и Xorg такое потребление - вполне нормально?
Для Xorg даже скромно :) Про гномотерминал не скажу, не использую, но да, подозрительно (хотя это один из самых неповоротливых терминалов).

>льсу вместо пульса не поставлю, это несколько нарушит целостность системы

Дык пульсаудио же вроде слой над альсой или осс.

> Дык пульсаудио же вроде слой над альсой или осс

Не совсем. pulse имеет тот же уровень, что и arts/esd. Более того - можно например работать через alsa минуя pulse. А alsa'вские приложения могут использовать pulse через специальный плагин:

Application -> Alsa -> Pulse plugin -> Pulse server -> Alsa(hw-level0) -> device :-)

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

ALSA никогда не была демоном (и, надеюсь, не будет)

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

Как уже было сказано, ALSA - не демон, а обычный набор библиотек и ядерных модулей, обеспечивающий работу со звуком, а PulseAudio - демон.

И приведённая схема: приложение -> ALSA -> Pulse Plugin -> PulseAudio -> ALSA (низкоуровневое) -> устройство, верна для случая, когда приложение не рассчитано на работу через pulse.

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

Как уже было сказано, ALSA - не демон, а обычный набор библиотек и ядерных модулей, обеспечивающий работу со звуком, а PulseAudio - демон.

И приведённая схема: приложение -> ALSA -> Pulse Plugin -> PulseAudio -> ALSA (низкоуровневое) -> устройство, верна для случая, когда приложение не рассчитано на работу через pulse.

>4660 eveel 20 0 198M 114M 15440 S 0.0 5.7 0:00.53 /usr/lib/opera/9.62/opera


Я всегда подозревал что внутри оперы firefox.

Думаю, там что-то покруче, чем firefox.

> Открыл с тремя вкладками - ушло 112М.

У меня 123 с 12 вкладками.

>...интерфейс и видео остаются на нормальном уровне.

Вот Вам глас народа! BSD - рулит и будет рулить!

> Вот Вам глас народа! BSD - рулит и будет рулить!

Вряд-ли... Скорее всего тут дело в Cocoa, Core Video, и остальных их тулкитов.