Dear readers :)
As you know, anything can be found in IRC. Serious talk, jokes, sex, politics, religion, anything you can spell between A and Z, it's all there :)
For me, IRC is like a virtual pub or cafe. I meet new people there, discuss computer stuff, brain storming, or simply just sit and do nothing...hahaha :)
two days, I visited #qemu channel on irc.freenode.net. This channel is the place to talk about Qemu, an open source emulator. I usually visit this channel to hear about latest issues, recent development or helping some folks with installation/runtime problem.
You think this channel is full with geek who can only code? Check this out :) it's a fragment of my qemu channel's log. filip2307 is Filip Navara, my remote friend from Czech republic..and malc...I dunno where he comes from :) The_hydra is /me FYI ( a bit scary nick name, eh?). Both malc and filip are frequent contributor for Qemu project. One word to describe them: GENIUS!
-------------------------------------------------------------------------------------
filip2307: geez ... who have invented the "hugetlbfs" name?! it's almost as readable as random letters...
the_hydra: hehe
the_hydra: =))
*** h7-25 has left #qemu
malc_: filip2307: you are spoiled by win32api with imaginative names like ntqueryprocessinformationtokenmyass..
-------------------------------------------------------------------------------------
I don't know if malc is just trying to put some laugh or he is just frustated with WinAPI naming :) Seems it is the latter one :)))))
Another funny quote:
-------------------------------------------------------------------------------------
filip2307 has quit IRC ("There are three important things in man's life: His birth, his first love and the day when he tastes cheesecake..")
-------------------------------------------------------------------------------------
Too bad it was a bit late to ask Filip, why the hell tasting cheesecake is so important? :)) I agree about first love, but cheesecake? Come on......
And last, I showed Filip my blog and he said (I rewrite this purely from my volatile RAM inside my brain, so surely something is different than the original on)
"Wow, I never saw so many "gw". Indonesian word is funny"
He thought, "gw" here is "gateway". After I told him it means "me", he began to scratch his head :)))
Keep the jokes coming dude....it makes our live colourful :)
regards
Mulyadi
25 October 2005
15 October 2005
Experiencing OOM (Out Of Memory) for the first time....
Hello Folks...
WARNING: DON'T TRY THIS TRICK ON YOUR PRODUCTION SERVER OR YOUR LOVELY WORKSTATION, AS THIS COULD LEAD TO DATA CORRUPTION. IF YOU REALLY WANT TO KNOW WITHOUT TAKING RISK, DO IT ON UNUSED PC OR INSIDE VIRTUAL MACHINE (EG: VMWARE)! I DON'T TAKE ANY RESPONSIBILIY FOR ANY DAMAGE THAT MIGHT HAPPEN. YOU'VE BEEN WARNED!
In the middle of writing my next article for CHIP, I am courious of one thing...that is "What will happen if mount an tmpfs based directory which has size way bigger than RAM+Swap and copy a huugeee file there"?. Pushed by courisity, I decide to test it.
First, here is how to create the "tmpfs" directory:
# mount -t tmpfs -o size=3G tmpfs /mytmpfs
You don't need to precisely use "3G". Just use any number that actually bigger than your RAM+swap. If you got trouble on determining your RAM + swap size, simply use "top" and check the related entries.
Confirm it via "df -h" that our new directory is actually mounted and the size is correct. Now, you need a big file, preferrably has same size like your new tmpfs directory. Don't have one? "dd" comes to rescue :)
# dd if=/dev/zero of=./coba.saja bs=1k count=1572864
That will roughly create a 1.5Gigabyte filled with zeros :) For final touch, copy it to "mytmpfs"
# cp ./coba.saja /mytmpfs
Just sit and enjoy the show. To bring more thrill, fire up "top" and watch your RAM and swap are slowly occupied by our giant file. Then, sooner or later, your Linux system will "freeze". It's not actually frozen. What really happens here is a race between kswapd (which tries to clear up RAM so you can put the file there) and "cp" (which tries to put the file there).
Your tasks are practically forced to swap out and this creates "frozen" effect. Why? because, in order to run, your application needs to be paged in..and that means, forcing kswapd to swap in the related pages and possibly swapping out pages which belongs to non active task. So. it's like:
your apps --> go to-> RAM < -- go to < -- your giant file
eventually, RAM and your swap is almost full. I said almost, because Linux kernel always reserve some pages for certain needs and these pages is non allocatable for user space applications. At this time, OOM(Out of Memory) killer kicks in! Sorry, I can't give you the screenshot :) In my PC, it wildly killed my X Session :) Thanks God, I only fired up several xterm and OpenOffice. Funny thing is, mpg123 is still playing (in "rap" mode...you know what I mean? ;) )
"can I choose which task I should kill in thise situation". Quick answer "No you can". Linux OOM killer employs simple algorithm that will kill an application which does the latest memory allocation. As you can see here, this isn't always a correct decision. But memory hogging tends to chew every single pieces of your RAM until last moment, so OOM killer is practically usable here.
Want another slow memory eater? try this
# tail -f /dev/zero
Until next time...until then, try to Google about "VM overcommit" for preventive solution :)
regards
Mulyadi
WARNING: DON'T TRY THIS TRICK ON YOUR PRODUCTION SERVER OR YOUR LOVELY WORKSTATION, AS THIS COULD LEAD TO DATA CORRUPTION. IF YOU REALLY WANT TO KNOW WITHOUT TAKING RISK, DO IT ON UNUSED PC OR INSIDE VIRTUAL MACHINE (EG: VMWARE)! I DON'T TAKE ANY RESPONSIBILIY FOR ANY DAMAGE THAT MIGHT HAPPEN. YOU'VE BEEN WARNED!
In the middle of writing my next article for CHIP, I am courious of one thing...that is "What will happen if mount an tmpfs based directory which has size way bigger than RAM+Swap and copy a huugeee file there"?. Pushed by courisity, I decide to test it.
First, here is how to create the "tmpfs" directory:
# mount -t tmpfs -o size=3G tmpfs /mytmpfs
You don't need to precisely use "3G". Just use any number that actually bigger than your RAM+swap. If you got trouble on determining your RAM + swap size, simply use "top" and check the related entries.
Confirm it via "df -h" that our new directory is actually mounted and the size is correct. Now, you need a big file, preferrably has same size like your new tmpfs directory. Don't have one? "dd" comes to rescue :)
# dd if=/dev/zero of=./coba.saja bs=1k count=1572864
That will roughly create a 1.5Gigabyte filled with zeros :) For final touch, copy it to "mytmpfs"
# cp ./coba.saja /mytmpfs
Just sit and enjoy the show. To bring more thrill, fire up "top" and watch your RAM and swap are slowly occupied by our giant file. Then, sooner or later, your Linux system will "freeze". It's not actually frozen. What really happens here is a race between kswapd (which tries to clear up RAM so you can put the file there) and "cp" (which tries to put the file there).
Your tasks are practically forced to swap out and this creates "frozen" effect. Why? because, in order to run, your application needs to be paged in..and that means, forcing kswapd to swap in the related pages and possibly swapping out pages which belongs to non active task. So. it's like:
your apps --> go to-> RAM < -- go to < -- your giant file
eventually, RAM and your swap is almost full. I said almost, because Linux kernel always reserve some pages for certain needs and these pages is non allocatable for user space applications. At this time, OOM(Out of Memory) killer kicks in! Sorry, I can't give you the screenshot :) In my PC, it wildly killed my X Session :) Thanks God, I only fired up several xterm and OpenOffice. Funny thing is, mpg123 is still playing (in "rap" mode...you know what I mean? ;) )
"can I choose which task I should kill in thise situation". Quick answer "No you can". Linux OOM killer employs simple algorithm that will kill an application which does the latest memory allocation. As you can see here, this isn't always a correct decision. But memory hogging tends to chew every single pieces of your RAM until last moment, so OOM killer is practically usable here.
Want another slow memory eater? try this
# tail -f /dev/zero
Until next time...until then, try to Google about "VM overcommit" for preventive solution :)
regards
Mulyadi
Subscribe to:
Posts (Atom)