----- Original Message ----- | Hi Bob, | | first of all, thank you for your amazing work. | | Do you include any kind of versioning with your releases so that we can check | what gfs2 version is running on our Gentoo with 3.1 kernel, and what version | is running on 2.6.32 kernel on centos? | The PHP processes hanging in D state are kinda annoying and it's not possible | to use the latest centos kernel due to severe crashes in certain conditions. | | Since I'm very familiar with kernels (Gentoo requires that you make your | own), I'm pretty sure that we can build and use a regular mainstream kernel | provided by kernel.org - it looks like there is also much development going | on by you and Mr. Whitehouse. | | You say that " The more recent the version, the better and faster GFS2 should | be" - do you mean the kernel version or GFS2 version? If the later, how can | we find out what version we're running? | | Thanks in advance, | Juergen Hi Jürgen, There aren't really any version markers to identify which patches are in which kernel. With the RHEL, Centos and Fedora versions, you can get the kernel version and trace that back to the tags in the source git repository. In other words, if you have a kernel version 2.6.32-358.20.1.el6, you can go back to the source repository and look through the commit messages to figure out what's in there. Aside from that, it's hard to tell what patches are where. It's not straightforward. Debugging performance problems are a challenge, and there are many many variables to look at. If it's a straight-up hang, we have tools like my "gfs2_hangalyzer" tool on my people page. http://people.redhat.com/rpeterso/Experimental/RHEL5.x/gfs2/gfs2_hangalyzer.c If it's not a true hang, but just slowness, you can check for GFS2 lock contention between the nodes with another tool I wrote: glocktop.c (same directory). The glocktop tool is like "top" in that it shows what glocks are being waited for, and their status. If it's a directory, it will even give you the directory name. The tool does its job by taking glock dumps and extracting the ones on which there are processes waiting. Before you run it, you should make sure your version of GFS2 has the patch for "faster glock dumps". With that patch, a glock dump should take less than a second. Without it, a glock dump can take a very long time. (A glock dump being the same as catting /sys/kernel/debug/gfs2/<lock table name>/glocks) If it's not glock contention, it could be many things. You just have to go through all the possibilities and see where the bottlenecks are. Yes, lots of development going on, still. :) When I spoke about using the most recent code, I meant the most recent GFS2 code, which is usually coupled to a given kernel. Regards, Bob Peterson Red Hat File Systems -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
