Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
[quote=morfik]Openbox działa dobrze, objawy wystąpiły dopiero po doinstalowaniu xcompmgr, ustapiły zaś po przejściu na comptona, także ewidentnie jest wina xcompmgr, temu pisałem, że gdyby zostało to poprawione (a raczej nie zostanie), to przeszedłbym na niego oszczędzając 25MiB ramu i dalatego też okrojenie pod tym względem by było korzystne, przynajmniej jeśli patrzeć z mojego punktu widzenia.[/quote]
To idąc dalej z oszczędzaniem — używaj samego Openboxa ;)
Offline
No właśnie nie mogę bo przeciągnie okien powoduje wtedy zużycie 100% procesora przez xorga i ten menadżer kompozycji został wprowadzony tylko i wyłącznie po to by pozbyć się obciążenia procesora, nic więcej od niego nie chcę.
Offline
No to się zdecyduj:
[quote=morfik]Openbox działa dobrze, objawy wystąpiły dopiero po doinstalowaniu xcompmgr[/quote]
;)
W jaki sposób sprawdzasz zużycie pamięci? Bo u mnie daleko do 25 mb.
Summary
The process compton (with pid 1444) is using approximately 2.0 MB of memory.
It is using 2032.0 KB privately, and a further 1564.0 KB that is, or could be, shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 39.0 KB. Adding that to the private usage, we get the above mentioned total memory footprint of 2.0 MB.
Library Usage
The memory usage of a process is found by adding up the memory usage of each of its libraries, plus the process's own heap, stack and any other mappings.
Private
1620 KB [heap]
92 KB /usr/bin/compton
48 KB /usr/lib/x86_64-linux-gnu/libconfig.so.9.1.2
28 KB /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
24 KB /lib/x86_64-linux-gnu/libc-2.17.so
Shared
536 KB /lib/x86_64-linux-gnu/libc-2.17.so
344 KB /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
104 KB /lib/x86_64-linux-gnu/ld-2.17.so
96 KB /lib/x86_64-linux-gnu/libm-2.17.so
64 KB /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
[b]Totals
Private 2048 KB (= 136 KB clean + 1912 KB dirty)
Shared 1564 KB (= 1564 KB clean + 0 KB dirty)
Rss 3612 KB (= Private + Shared)
Pss 2088 KB (= Private + Shared/Number of Processes)
Swap 0 KB[/b][/quote]
PS Bez tych 25 mb comptona system działa ci zauważalnie szybciej?
Offline
jak juz się licytujemy na MB w pamięci to może fluxbox ?
bez przesady, w dzisiejszych czasach kto się przejmuje pamięcią RAM? 8GB pamięci kosztuje jakieś grosze i ja szczerze mówiąc ciesze się, jak system trzyma wszystko w pamięci bo ma szybciej sięgać po zasoby
sam mam 8GB pamięci i o ile nie gram, ciężko mi zużyć 15% przy odpalonym systemie ze wszystkimi potrzebnymi i nie potrzebnymi aplikacjami i bajerami
Offline
Debian wheezy i386 z xfce 4.8 po odchudzeniu pobierał mi około 70 MB pamięci i niewiele zasobów procesora...
Offline
[quote=yossarian]No to się zdecyduj:[/quote]
No nie ma efektów jak przedstawionych na filmiku, pod tym względem działa dobrze. xD Natomiast jest inny ficzer, który powoduje że przy przeciąganiu okien bez menadżera kompozycji xorg leci na 100% zuzycia procesora.
[quote=yossarian]W jaki sposób sprawdzasz zużycie pamięci? Bo u mnie daleko do 25 mb.[/quote]
Przez:
ps -eo "%mem pid user args"
Coś nie tak z tym?
[quote=yossarian]PS Bez tych 25 mb comptona system działa ci zauważalnie szybciej?[/quote]
Nie wiem jak może działać szybciej gdy byle przeciągnie okna zjada cały procesor. xD
[quote=urbinek]bez przesady, w dzisiejszych czasach kto się przejmuje pamięcią RAM?[/quote]
Ja się przejmuję — mam 1 GiB i za drugie tyle robi dysk xD
Offline
[quote=morfik][quote=yossarian]W jaki sposób sprawdzasz zużycie pamięci? Bo u mnie daleko do 25 mb.[/quote]
Przez:
ps -eo "%mem pid user args"
Coś nie tak z tym?[/quote]
U mnie wygląda to tak:
0.0 1444 yossari+ compton --config /home/yossarian/.compton.conf -b
Użycie jest znikome. Bez Comptona również wszystko zawsze u mnie dobrze działało.
Wygląda na to, że to jakiś folklor u Ciebie. Nie jest to żadna jednoznaczna wina Openboksa czy Comptona.
Przynajmniej nie da się tego w prosty sposób odtworzyć na innych konfiguracjach.
[quote=yossarian]PS Bez tych 25 mb comptona system działa ci zauważalnie szybciej?[/quote]
Nie wiem jak może działać szybciej gdy byle przeciągnie okna zjada cały procesor. xD[/quote]
No to czy po zwolnieniu innego procesu, dzięki czemu odzyskasz te 25 MiB, zauważasz różnicę?
Offline
A mógłbyś mi podać konfig?
Ile masz ramu? xD
I jeśli dobrze rozumiem, nigdy nie miałeś problemów ze skokiem procka do 100% przy przeciąganiu okien?
[quote=yossarian]No to czy po zwolnieniu innego procesu, dzięki czemu odzyskasz te 25 MiB, zauważasz różnicę?[/quote]
To zależy, póki nie zapełniam ramu po nad 1GiB, to nie. Ale zwykle mam na granicy także, różnie bywa.
Offline
[quote=morfik][quote=urbinek]bez przesady, w dzisiejszych czasach kto się przejmuje pamięcią RAM?[/quote]
Ja się przejmuję — mam 1 GiB i za drugie tyle robi dysk xD[/quote]
[quote=morfik]To zależy, póki nie zapełniam ramu po nad 1GiB, to nie. Ale zwykle mam na granicy także, różnie bywa.[/quote]
to może ci dysk bruździ ?
Ja swojego czasu na 1 GB ramu +1(albo 2) GB swap miałem uruchomione 4 maszyny wirtualne z xpekiem, operę z 50 zakładkami i nagrywałem całość krecordmydesktop
nic nie muliło zbytnio a miałem normalne kde 3.5 z compizem nawet zdaje się
Offline
bez opóźnień, mogłem bez problemu przełączać się między systemami itp,
wszystko chodziło ok do momentu gdy miałem 98% zużycia RAMu i system się wieszał wtedy włączyłem SWAP i problem zniknął
a bruździć może na zasadzie takiej iż może umiera?
masz swap na dysku systemowym? spróbuj go wyłaczyć
Offline
Póki wszystkie dane są w ramie, to nie ma problemu, a chodzi o to właśnie, że system zaczyna zwalniać jak tych danych jest tyle, że się w ramie już nie mieszczą i temu przydaje się odciążyć system ze zbędnych rzeczy. Choć mi by się na tym 1GiB 4 maszyny virtualne + opera z 50 zakładkami na pewno nie zmieściły. A ze swap? Na pewno by się cięło, sama opera by z 1 GiB zajmowała, z czego 70% by zostało zrzucone do swap i system by próbował załadować maszynę virtualną częściowo zrzucają ja też do swap, a że przy maszynie by potrzebował praktycznie wszystkich jej danych, to dysk by rył niesamowicie spowalniając tym samym pracę o xxx razy. Oczywiście rozmawiamy o procku co nie posiada virtualizacji.
Offline
[quote=morfik]A mógłbyś mi podać konfig?
Ile masz ramu? xD
I jeśli dobrze rozumiem, nigdy nie miałeś problemów ze skokiem procka do 100% przy przeciąganiu okien?
[quote=yossarian]No to czy po zwolnieniu innego procesu, dzięki czemu odzyskasz te 25 MiB, zauważasz różnicę?[/quote]
To zależy, póki nie zapełniam ramu po nad 1GiB, to nie. Ale zwykle mam na granicy także, różnie bywa.[/quote]
Chodzi o Comptona?
O ile dobrze pamiętam, to pobierałem standardowy config z gita:
# Shadow shadow = true; # Enabled client-side shadows on windows. no-dock-shadow = true; # Avoid drawing shadows on dock/panel windows. no-dnd-shadow = true; # Don't draw shadows on DND windows. clear-shadow = true; # Zero the part of the shadow's mask behind the window (experimental). shadow-radius = 7; # The blur radius for shadows. (default 12) shadow-offset-x = -7; # The left offset for shadows. (default -15) shadow-offset-y = -7; # The top offset for shadows. (default -15) # shadow-opacity = 0.7; # The translucency for shadows. (default .75) # shadow-red = 0.0; # Red color value of shadow. (0.0 - 1.0, defaults to 0) # shadow-green = 0.0; # Green color value of shadow. (0.0 - 1.0, defaults to 0) # shadow-blue = 0.0; # Blue color value of shadow. (0.0 - 1.0, defaults to 0) shadow-exclude = [ "n:e:Notification" ]; # Exclude conditions for shadows. # shadow-exclude = "n:e:Notification"; shadow-ignore-shaped = true; # Opacity menu-opacity = 0.95; # The opacity for menus. (default 1.0) inactive-opacity = 0.98; # Opacity of inactive windows. (0.1 - 1.0) frame-opacity = 0.90; # Opacity of window titlebars and borders. (0.1 - 1.0) inactive-opacity-override = true; # Inactive opacity set by 'inactive-opacity' overrides value of _NET_WM_OPACITY. # Fading fading = true; # Fade windows during opacity changes. # fade-delta = 30; # The time between steps in a fade in milliseconds. (default 10). fade-in-step = 0.03; # Opacity change between steps while fading in. (default 0.028). fade-out-step = 0.03; # Opacity change between steps while fading out. (default 0.03). # no-fading-openclose = true; # Fade windows in/out when opening/closing. # Other #inactive-dim = 0.5; # Dim inactive windows. (0.0 - 1.0, defaults to 0). mark-wmwin-focused = true; # Try to detect WM windows and mark them as active. mark-ovredir-focused = true; detect-rounded-corners = true; # Window type settings wintypes: { tooltip = { fade = true; shadow = false; opacity = 0.75; }; };
Co do Ramu, obecnie to wygląda tak:
free -m total used free shared buffers cached Mem: 3871 2712 1158 0 50 1223 -/+ buffers/cache: 1439 2431 Swap: 0 0 0
Akurat Chromium tu sporo zjada. Próbuję się przesiadać z Opery na Chromium/Iceweasela.
Problemów nigdy takich nie miałem z tym przesuwaniem okien. W ogóle to żadnych ;)
A tu był KDE4 na netbooku:
http://forum.dug.net.pl/viewtopic.php?pid=190677#p190677
Działało to całkiem znośnie. Trochę ociężale, ale dawało się spokojnie używać. Coś jak obecne Ubuntu na normalnym sprzęcie ;)
Jeżeli się nie przesadzało z ilością kart (szczególnie w Chromium), to działało całkiem bezproblemowo z taka ilością pamięci.
Dziwne, że masz takie problemy z lekkim menedżerem okien.
Offline
Mi na tym samym configu zjada dokładnie tyle samo ramu co zjadał wcześniej. Poza tym, ciekawą rzecz zaobserwowałem. Bo mam na pulpicie 4 conky + terminator. I gdy przesuwam okno w obrębie terminatora przy wyłączonym comptonie, xorg nie skacze, natomiast jak ciągane okno wjedzie na conky, to wtedy i conky i xorg próbują zjadać 100% procka i okno zostawia lekkie widmo. To może jednak z configiem conka jest nie tak.
Ostatnio edytowany przez morfik (2013-08-17 18:51:38)
Offline
Ktoś już miał na forum jakieś dziwne rzeczy z conky. Chyba chodziło o użycie dysku.
Sprawdź ten trop z Conky.
Offline
To jednak nie jest problem conkiego. Przesuwanie okien pierwszoplanowych na tle innych powoduje wzrost zużycia procka przez proces (i xorga) który wykorzystuje to okno w tle. Czyli jak przeciągam okno i w tle jest conky, to conky + xorg dzielą się procem tak by wykorzystać go w 100%, i jeśli bym miał w tle np okno geany. to wtedy xorg z geany by sobie proc podzieliły i też by wykorzystywały w 100%. Dziwna sprawa. xD
Offline
[quote=morfik]No właśnie nie mogę bo przeciągnie okien powoduje wtedy zużycie 100% procesora przez xorga i ten menadżer kompozycji został wprowadzony tylko i wyłącznie po to by pozbyć się obciążenia procesora, nic więcej od niego nie chcę.[/quote]
Przepraszam za odkopanie tematu. Od kilku lat używam openboxa i nigdy nie miałem takich objawów do czasu kiedy zainstalowałem sobie do testów sida z openboxem i lightdm. Z moich obserwacji wynika, że openbox + lightdm - procek szaleje, openbox + slim - procek w spokoju (przynajmniej w porównaniu do poprzedniej pary). Nie korzystam z comptona.
Offline
Według mnie wybór środowiska powinien zależeć od właściciela komputera.
Kiedyś byłem użytkownikiem KDE, Gnome, LXDE (a teraz Xfce4). Ostatnio zrobiłem sobie maraton, na co by tu przejść
1) E17 odpadło, nie wiem czemu ale wyzwolił we mnie jakąś agresję, czułem się wtedy tak wkurzony, że od razu reinstall
2) LXDE jest w teorii fajne, ale boryka się z błędami i ma niestety - braki
3) Gnome jest fenomenalne, ale bywa niestabilne - a to boli ...
4) KDE jest fenomenalne, ale praktycznie User Friendly. Nic w tym złego, ale powstał (moim zdaniem) system dla przeciętnego użytkownika. Dodatkowo ma swoje wymagania
5) Xfce4 wybrałem dlatego, że swoją funkcjonalnością oferuje bardzo dużo (ustawienia), a zarazem jest szybki i niezawodny (nigdy [chyba] nie widziałem crasha Panelu Xfce4, czy innego problemu), wymaga niestety (częściowo) aplikacji z Gnome (bo nie ma odpowiednika w GTK / QT [QT bez KDE]), ale ogólnie jest to "me gusta"
Fervi
Offline
Fervi spróbuj openboxa ;p
[quote=zbig]Przepraszam za odkopanie tematu. Od kilku lat używam openboxa i nigdy nie miałem takich objawów do czasu kiedy zainstalowałem sobie do testów sida z openboxem i lightdm. Z moich obserwacji wynika, że openbox + lightdm - procek szaleje, openbox + slim - procek w spokoju (przynajmniej w porównaniu do poprzedniej pary). Nie korzystam z comptona.[/quote]
jaki masz procesor? oraz gdy to się dzieije daj screena z htop (posortowane według użycia %CPU)
Offline
U mnie też działa, tylko musiałem trochę czasu posiedzieć ale obecnie nie mam chyba żadnych problemów, albo mam i o tym nie wiem. xD W każdym razie ja tego typu zachowanie (wzrost % cpu) miałem zawsze, nawet na gnome, ale myślałem wtedy, że to nie bug ale ficzer i że wszyscy tak mają.
Offline
Ja nigdy nie miałem takich problemów.
Offline
[quote=zbi]... do czasu kiedy zainstalowałem sobie do testów sida ...[/quote]
i tu chyba był "pies pogrzebany", bo po kolejnej aktualizacji wszystko wróciło do normy.
Offline
Time (s) | Query |
---|---|
0.00009 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00093 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.142.210.173' WHERE u.id=1 |
0.00069 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.142.210.173', 1732219420) |
0.00040 | SELECT * FROM punbb_online WHERE logged<1732219120 |
0.00048 | SELECT topic_id FROM punbb_posts WHERE id=242638 |
0.00228 | SELECT id FROM punbb_posts WHERE topic_id=24079 ORDER BY posted |
0.00074 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=24079 AND t.moved_to IS NULL |
0.00008 | SELECT search_for, replace_with FROM punbb_censoring |
0.00187 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=24079 ORDER BY p.id LIMIT 25,25 |
0.00085 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=24079 |
Total query time: 0.00845 s |