Re: x86_64 and memory usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adam Nielsen wrote: Lot's of graphs and progressbars, I guess. And running my main instance under valgrind isn't really an option to me, that's just way too awfully slow. :( Of course if you're not familiar with the code this will be tricky, but it's probably the best way to hunt down these types of issues. *chuckle* Well another option would be to disable all your progress bars and see if the leak rate changes. If you then add back lots of one type of progress bar you might be able to narrow down the leak to a particular component. Also don't forget if you're launching external scripts and things the leak could be happening outside of Awesome. FWIW mine seems to have increased since yesterday though: 3357 adam 20 0 375m 192m 13m S0 2.4 10:56.14 awesome I don't have any widgets running besides the defaults. valgrind --tool=massif says: - -16.63% (2,138,520B) 0x431508: image_getdata (util.h:148) - -14.11% (1,814,400B) 0x300441002C: imlib_create_image (in /usr/lib/libImlib2.so.1.4.2) (This is the top memory usage outside of liblua and I'll just assume it's not lua's fault for now...) (Oh and liblua was at 44% a while after startup and is now at 40.5%, so looking at it relatively, it actually decreased) Anyone else feels like 4 MiB for images is way too much? So this might be due to my 5 progressbar and 4 graph widgets (and perhaps the icons from the tasklist). Cheers Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLw2SVAAoJECLkKOvLj8sGZQEH/AjXw7eyR9aOkg5qhW9IA+Pp RdHiq5JFrn7tvjMTvJuKkQsw0iC5FemhwtMRmSe5Lf142FdAOccX/9fhzFmRTSJc V+SPir4Fsdm3U8krI5Gu+SRFluiuHewOy8hWcRn85+gg/dQDnb4wTP2ehrpbuePF RS3XThRXaw8zQrlmekjncjdJ+wzQU5HsG6PcwOVO2sQ3bath65I28h3LUZmUdsGL B/At/q3JFYeTPbWwYXDUnzfE13yA2h+9y39MDZHGQnswtfIVgvu11xthpGVtYOJQ 42zKzyrEWZRPlGQIFn+2Uv6UL2pTqwnOH8mKstSEKBYRXLvfKx/0PiZlvJ+xmdg= =9NMW -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
Lot's of graphs and progressbars, I guess. And running my main instance under valgrind isn't really an option to me, that's just way too awfully slow. :( Of course if you're not familiar with the code this will be tricky, but it's probably the best way to hunt down these types of issues. *chuckle* Well another option would be to disable all your progress bars and see if the leak rate changes. If you then add back lots of one type of progress bar you might be able to narrow down the leak to a particular component. Also don't forget if you're launching external scripts and things the leak could be happening outside of Awesome. FWIW mine seems to have increased since yesterday though: 3357 adam 20 0 375m 192m 13m S0 2.4 10:56.14 awesome I don't have any widgets running besides the defaults. Cheers, Adam. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adam Nielsen wrote: Just FYI, it gets worse over time. ;) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 472m 313m 4304 R 0.8 16.1 20:35.80 /home/psychon/projects/awesome/awesome $ uptime 11:06:19 up 2 days, 23:42, 1 user, load average: 2.12, 2.11, 2.19 It doesn't seem so bad here: up 10 days, 20:48 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3357 adam 20 0 355m 172m 13m S2 2.2 9:15.40 awesome top - 17:06:32 up 4 days, 5:42, 2 users, load average: 2.66, 2.56, 2.36 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 780m 620m 4364 S 0.2 32.0 36:45.75 /home/psychon/projects/awesome/awesome This got so bad that awesome could no longer fork new processes: [pid 10159] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fbbf5344800) = -1 ENOMEM (Cannot allocate memory) Before restart: total used free sharedbuffers cached Mem: 1940 1842 98 0 42507 - -/+ buffers/cache: 1292648 Swap: 2047 30 2017 After restart: total used free sharedbuffers cached Mem: 1940 1242698 0 43514 - -/+ buffers/cache:684 1256 Swap: 2047 28 2019 No idea how one could best tackle these... You're probably using some part of Awesome that I am not hitting as much, so I guess the only way to start tackling the issue is to run Awesome through something like Valgrind, and dig into the code to figure out where the memory is being used up. Lot's of graphs and progressbars, I guess. And running my main instance under valgrind isn't really an option to me, that's just way too awfully slow. :( I had 620m of memory usage after 4 days 5h (=101h), which means this is on average 6m of leak per hour. Running a second instance in Xephyr to get a list of leaks seems painful. :/ And if that leak requires interaction with awesome (e.g. changing a window's border or whatever), then good luck. Meh. Of course if you're not familiar with the code this will be tricky, but it's probably the best way to hunt down these types of issues. *chuckle* I'll see what I can come up with. Cheers, Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLu0+7AAoJECLkKOvLj8sGQe8IAJN70cTshFqHMtEqh5AnF8fQ PuhfUKSV9NI5U2MnFOEP5pYuCIZZkkHB8zHv3sD0+07+40Ow5B9UtkPzczYPZre+ 92ScFaF2grvCUV5RPODIGvi2f6nQ3GYOTZi4tJu6eHDcdJWJNVruAhkROoJcMyOt JTN7rJET0nHJYsVgdhTVcA9JPe4ucrcgI5MIK66x5GDFJ3+n6Qf7/fthkezRi9yJ 2f6GJkDRym/KuBr7Jm2Sm+aDosoP7Ph6sZhgmXbC8CknaI7/yw16vraH5w7T9nK0 p68TP+jbeyK/sq1j/JWgVvlwjvfEl62Xd7eYafjyMlTA+gvVi4NB2BevqXo7YM8= =Gw9G -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
Lot's of graphs and progressbars, I guess. And running my main instance under valgrind isn't really an option to me, that's just way too awfully slow. :( Of course if you're not familiar with the code this will be tricky, but it's probably the best way to hunt down these types of issues. *chuckle* Well another option would be to disable all your progress bars and see if the leak rate changes. If you then add back lots of one type of progress bar you might be able to narrow down the leak to a particular component. Also don't forget if you're launching external scripts and things the leak could be happening outside of Awesome. FWIW mine seems to have increased since yesterday though: 3357 adam 20 0 375m 192m 13m S0 2.4 10:56.14 awesome I don't have any widgets running besides the defaults. Cheers, Adam. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
Just FYI, it gets worse over time. ;) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 472m 313m 4304 R 0.8 16.1 20:35.80 /home/psychon/projects/awesome/awesome $ uptime 11:06:19 up 2 days, 23:42, 1 user, load average: 2.12, 2.11, 2.19 It doesn't seem so bad here: up 10 days, 20:48 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3357 adam 20 0 355m 172m 13m S2 2.2 9:15.40 awesome No idea how one could best tackle these... You're probably using some part of Awesome that I am not hitting as much, so I guess the only way to start tackling the issue is to run Awesome through something like Valgrind, and dig into the code to figure out where the memory is being used up. Of course if you're not familiar with the code this will be tricky, but it's probably the best way to hunt down these types of issues. Cheers, Adam. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Adam Nielsen wrote: Just FYI, it gets worse over time. ;) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 472m 313m 4304 R 0.8 16.1 20:35.80 /home/psychon/projects/awesome/awesome $ uptime 11:06:19 up 2 days, 23:42, 1 user, load average: 2.12, 2.11, 2.19 It doesn't seem so bad here: up 10 days, 20:48 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3357 adam 20 0 355m 172m 13m S2 2.2 9:15.40 awesome top - 17:06:32 up 4 days, 5:42, 2 users, load average: 2.66, 2.56, 2.36 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 780m 620m 4364 S 0.2 32.0 36:45.75 /home/psychon/projects/awesome/awesome This got so bad that awesome could no longer fork new processes: [pid 10159] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fbbf5344800) = -1 ENOMEM (Cannot allocate memory) Before restart: total used free sharedbuffers cached Mem: 1940 1842 98 0 42507 - -/+ buffers/cache: 1292648 Swap: 2047 30 2017 After restart: total used free sharedbuffers cached Mem: 1940 1242698 0 43514 - -/+ buffers/cache:684 1256 Swap: 2047 28 2019 No idea how one could best tackle these... You're probably using some part of Awesome that I am not hitting as much, so I guess the only way to start tackling the issue is to run Awesome through something like Valgrind, and dig into the code to figure out where the memory is being used up. Lot's of graphs and progressbars, I guess. And running my main instance under valgrind isn't really an option to me, that's just way too awfully slow. :( I had 620m of memory usage after 4 days 5h (=101h), which means this is on average 6m of leak per hour. Running a second instance in Xephyr to get a list of leaks seems painful. :/ And if that leak requires interaction with awesome (e.g. changing a window's border or whatever), then good luck. Meh. Of course if you're not familiar with the code this will be tricky, but it's probably the best way to hunt down these types of issues. *chuckle* I'll see what I can come up with. Cheers, Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLu0+7AAoJECLkKOvLj8sGQe8IAJN70cTshFqHMtEqh5AnF8fQ PuhfUKSV9NI5U2MnFOEP5pYuCIZZkkHB8zHv3sD0+07+40Ow5B9UtkPzczYPZre+ 92ScFaF2grvCUV5RPODIGvi2f6nQ3GYOTZi4tJu6eHDcdJWJNVruAhkROoJcMyOt JTN7rJET0nHJYsVgdhTVcA9JPe4ucrcgI5MIK66x5GDFJ3+n6Qf7/fthkezRi9yJ 2f6GJkDRym/KuBr7Jm2Sm+aDosoP7Ph6sZhgmXbC8CknaI7/yw16vraH5w7T9nK0 p68TP+jbeyK/sq1j/JWgVvlwjvfEl62Xd7eYafjyMlTA+gvVi4NB2BevqXo7YM8= =Gw9G -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [AvataR] wrote: Recently I switch to x86_64, and found, that awesome eats to many memory, and looks like some leaks presents, even on default configuration. 22328 avatar20 0 253M 40760 15904 S 0.0 1.0 0:57.80 awesome It starts with 25000, and 244M virtual Just FYI, it gets worse over time. ;) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 472m 313m 4304 R 0.8 16.1 20:35.80 /home/psychon/projects/awesome/awesome $ uptime 11:06:19 up 2 days, 23:42, 1 user, load average: 2.12, 2.11, 2.19 No idea how one could best tackle these... Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLuaiIAAoJECLkKOvLj8sGk1QIALYF8yCLKlbRsGGKI56NDvFN d+MnFxTvI3lUm9Obx1q3eNfn3O3QZB8oSNVrzzwdi1DP/VEKiQpTkvSxc8qpsRCx QTB+C649UsDwb4I4ViuNGnS82KV0jFJrzwDTXLkfbi0mDSCaNBIWTQTAMQNTCh5k cyO2mnfGUz9O+lzhT7/IvWEkFTKjjCda60lieSdQSBBcscVaL5sjlAABOth8o9Pt tsV5yBYkJgiZHUt642tg+tHwNGtXSI81GUL//hWNftCERjb9wLr+Wh+F5TmkuNhb LTKpLGlE+B8Vn8q9SOvm0og9jnwbin4OGzxCvvOkEHndlCDdjxbU1gQfjTZAVyY= =dRcj -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
Just FYI, it gets worse over time. ;) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 472m 313m 4304 R 0.8 16.1 20:35.80 /home/psychon/projects/awesome/awesome $ uptime 11:06:19 up 2 days, 23:42, 1 user, load average: 2.12, 2.11, 2.19 It doesn't seem so bad here: up 10 days, 20:48 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3357 adam 20 0 355m 172m 13m S2 2.2 9:15.40 awesome No idea how one could best tackle these... You're probably using some part of Awesome that I am not hitting as much, so I guess the only way to start tackling the issue is to run Awesome through something like Valgrind, and dig into the code to figure out where the memory is being used up. Of course if you're not familiar with the code this will be tricky, but it's probably the best way to hunt down these types of issues. Cheers, Adam. -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
x86_64 and memory usage
Recently I switch to x86_64, and found, that awesome eats to many memory, and looks like some leaks presents, even on default configuration. 22328 avatar20 0 253M 40760 15904 S 0.0 1.0 0:57.80 awesome It starts with 25000, and 244M virtual -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: x86_64 and memory usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [AvataR] wrote: Recently I switch to x86_64, and found, that awesome eats to many memory, and looks like some leaks presents, even on default configuration. 22328 avatar20 0 253M 40760 15904 S 0.0 1.0 0:57.80 awesome It starts with 25000, and 244M virtual Just FYI, it gets worse over time. ;) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2486 psychon 20 0 472m 313m 4304 R 0.8 16.1 20:35.80 /home/psychon/projects/awesome/awesome $ uptime 11:06:19 up 2 days, 23:42, 1 user, load average: 2.12, 2.11, 2.19 No idea how one could best tackle these... Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLuaiIAAoJECLkKOvLj8sGk1QIALYF8yCLKlbRsGGKI56NDvFN d+MnFxTvI3lUm9Obx1q3eNfn3O3QZB8oSNVrzzwdi1DP/VEKiQpTkvSxc8qpsRCx QTB+C649UsDwb4I4ViuNGnS82KV0jFJrzwDTXLkfbi0mDSCaNBIWTQTAMQNTCh5k cyO2mnfGUz9O+lzhT7/IvWEkFTKjjCda60lieSdQSBBcscVaL5sjlAABOth8o9Pt tsV5yBYkJgiZHUt642tg+tHwNGtXSI81GUL//hWNftCERjb9wLr+Wh+F5TmkuNhb LTKpLGlE+B8Vn8q9SOvm0og9jnwbin4OGzxCvvOkEHndlCDdjxbU1gQfjTZAVyY= =dRcj -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Fwd: x86_64 and memory usage
[AvataR] wrote: Recently I switch to x86_64, and found, that awesome eats to many memory, and looks like some leaks presents, even on default configuration. 22328 avatar 20 0 253M 40760 15904 S 0.0 1.0 0:57.80 awesome It starts with 25000, and 244M virtual Just FYI, it gets worse over time. ;) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2486 psychon 20 0 472m 313m 4304 R 0.8 16.1 20:35.80 /home/psychon/projects/awesome/awesome $ uptime 11:06:19 up 2 days, 23:42, 1 user, load average: 2.12, 2.11, 2.19 No idea how one could best tackle these... I don't seem to have this problem here, been running awesome on x86_64 for... ages without problem. top - 17:45:58 up 4 days, 8:52, 3 users, load average: 0.61, 0.68, 0.71 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 11.0%us, 2.9%sy, 0.1%ni, 84.1%id, 1.3%wa, 0.2%hi, 0.4%si, 0.0%st Mem: 3343812k total, 2840624k used, 503188k free, 0k buffers Swap: 4000180k total, 286060k used, 3714120k free, 737140k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2148 cycojesu 20 0 207m 26m 2840 S 2 0.8 13:57.80 awesome Note that this is latest from git on slackware64-current. EDIT: forgot to send to awesome-devel, sorry -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
