Rahul Bhargava on Evolphin & Technology

When you install Fedora Core, it appears the beagle indexing service is started in the background automatically. On my machine, beagle was consuming too many resources. In order to stop the damn thing, I had to tear my hairs!

The beagle daemon for one is not installed as a normal /etc/init.d or xinetd service. The following recipe worked for me, might need to scipt it and launch it from the bashrc when loggin in:

1. $ beagled –disable-schedule ( this would disable the scheduler)
2. $ beagle-settings (This brings up a GUI to stop it from indexing, just deselect the options, see the screen shot below)
   
3. $ beagle-shutdown (now the damn service should be gone)
4. $ beagle-info –status
   Could not connect to the daemon.

If you see the last line, you are set!

The fabolous thing about upgrading to Fedora Core 6 has been that the yum package manager now routinely hangs on my machine. This does not make for a fun experiecne. For me it typically hangs hard after a pop-up message:

Retreiving software information

A little bit of detective work in another terminal indicates why:

# ps -leaf | grep `cat /var/run/yum.pid`

This number is Pirut’s yum process ID. Let’s see what it’s stuck doing:

# strace -p `cat /var/run/yum.pid
[root@rahul ~]# strace -p 2524
Process 2524 attached – interrupt to quit
ioctl(4, FIONREAD, [0])                 = 0
poll( <unfinished …>

Check, this out; it is waiting in a poll system call. This usually implies that the process is waiting for a network IO event to happen. If the previous pirut process is gone, well, things can get to this mess. By the way, it is possible to nuke pirut yum at this point; you just have to be brutal.

# pkill -9 pirut

Once this is done, a little digging around often shows a couple of __db.* files in /var/lib/rpm. Let’s nule all of these:

# rm -rf /var/lib/rpm/__db.*

At this juncture, retrying the hung yum/pirut command should work. At least, it does so for me. Sometimes, I need to run “yum clean all” after cleaning up the above mess before yum can make progress.

This article was originally posted by me on theserverside.com, it is reproduced here

I have been benchmarking Java NIO with various JDKs on Linux. Server is running on a 2 CPU 1.7 GHz, 1GB RAM, Ultra160 SCSI 36GB disk

With Linux kernel 2.6.5 (Gentoo) I had NPTL turned on and support for epoll compiled in. The server application was designed to support multiple disptach models :

1. Reactor with Iterative Disptach with multiple selector threads. Essentially the accepted connections were load-balanced between varying number of selector threads. The benchmark then applied a step function to experimentally determine the optimal # of threads and connection per selector ratio.
2. Also a simple concurrent blocking disptach model was supported. This is essentially a reader thread per connection model.

Read the rest of this entry »