Messages in this thread | | | Date | Thu, 8 Apr 1999 13:26:00 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: Tasks raising to 95% of %CPU / SOLVED |
| |
On Thu, 8 Apr 1999, Eduardo Soriano wrote: > Environment: Linux 2.0.36 RedHat 5.2
it's not clear from context, and i didn't see the beginning of this thread. is this also a problem with 2.2.x kernels? would this be a reasonable change for administrators running, say, a directory server on recent versions of Linux?
> Kernel updates: > > 1. From Alan Cox (alan@lxorguk.ukuu.org.com) > ----------------------------------------- > > > If you edit fs/ext2/dir.c and rebuild a kernel with the fsync entry in > > the file operations set to file_fsync > > > > ie to > > > > static struct file_operations ext2_dir_operations = { > > NULL, /* lseek - default */ > > ext2_dir_read, /* read */ > > NULL, /* write - bad */ > > ext2_readdir, /* readdir */ > > NULL, /* select - default */ > > ext2_ioctl, /* ioctl */ > > NULL, /* mmap */ > > NULL, /* no special open code */ > > NULL, /* no special release code */ > > file_sync, /* fsync */ > > NULL, /* fasync */ > > NULL, /* check_media_change */ > > NULL /* revalidate */ > > }; > > No impact. The system worked properly last Thursday but in fact it was > a day with few inserts > > > 2. From Franz J Fortuny (ffortuny@ivsol.com) > ----------------------------------------- > > You must recompile the kernel so that file in > /usr/src/linux/fs/ext2/file.c should look like: > > 64 static struct file_operations ext2_file_operations = { > 65 ext2_file_lseek, /* lseek */ > 66 generic_file_read, /* read */ > 67 ext2_file_write, /* write */ > 68 NULL, /* readdir - bad */ > 69 NULL, /* poll - default */ > 70 ext2_ioctl, /* ioctl */ > 71 generic_file_mmap, /* mmap */ > 72 #if BITS_PER_LONG == 64 > 73 NULL, /* no special open is > needed */ > 74 #else > 75 ext2_open_file, > 76 #endif > 77 NULL, /* flush */ > 78 ext2_release_file, /* release */ > ----> 79 file_fsync, /* fsync */ > 80 NULL, /* fasync */ > 81 NULL, /* check_media_change */ > 82 NULL /* revalidate */ > 83 }; > > Line 79 is the one that needs to be modified. > > On 2.0.36 this upgrade becomes: > > extern int file_fsync(); > > /* > * We have mostly NULL's here: the current defaults are ok for > * the ext2 filesystem. > */ > static struct file_operations ext2_file_operations = { > NULL, /* lseek - default */ > generic_file_read, /* read */ > ext2_file_write, /* write */ > NULL, /* readdir - bad */ > NULL, /* select - default */ > ext2_ioctl, /* ioctl */ > generic_file_mmap, /* mmap */ > NULL, /* no special open is needed */ > ext2_release_file, /* release */ > /* > ext2_sync_file, > */ > file_fsync, /* fsync */ > NULL, /* fasync */ > NULL, /* check_media_change */ > NULL /* revalidate */ > }; > > > This patch solved the problem. > > Problem reason: > -------------- > > Solid DB is currently stored on a single file large of 500M > > According with solid documentation, a daemon is started on every 5000 inserts > performed on the DB in order to complete a CheckPoint. > > This checkpoint operation required 1 minute and 50 seconds to be completed. > At that time, the system was overloaded and unable to handle remote > requests. > > The new kernel with file.c upgrade requires now 4 seconds to complete the > same task. > > Even more, solid server "feels" to work 30% faster, but we have not checked > this feeling with appropriate tools. We had no references about a referenced > transaction when using the "slow" kernel. > > > Many thanks to Alan and Franz for their help. > > Bye > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ >
- Chuck Lever -- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project: http://www.citi.umich.edu/projects/citi-netscape/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |