Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 96201 invoked from network); 12 Feb 2007 15:09:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Feb 2007 15:09:04 -0000 Received: (qmail 11919 invoked by uid 500); 12 Feb 2007 15:08:59 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 11678 invoked by uid 500); 12 Feb 2007 15:08:58 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 11663 invoked by uid 99); 12 Feb 2007 15:08:58 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Feb 2007 07:08:58 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [212.45.32.108] (HELO mailrelay02.solcon.nl) (212.45.32.108) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Feb 2007 07:08:46 -0800 Received: from [212.45.32.70] (helo=srv-solcon-01.solcon.local) by mailrelay02.solcon.nl with esmtp (Exim 4.60) (envelope-from ) id 1HGcmz-00010B-6l for users@httpd.apache.org; Mon, 12 Feb 2007 16:08:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74EB7.A3BB6EF8" Date: Mon, 12 Feb 2007 16:08:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Graceful: stat64 DocumentRoot directories thread-index: AcdOt6NrRY0lrqodQnaPKwXHOwXCzA== From: "Jan van den Berg" To: X-Virus-Checked: Checked by ClamAV on apache.org Subject: [users@httpd] Graceful: stat64 DocumentRoot directories ------_=_NextPart_001_01C74EB7.A3BB6EF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a couple of questions about the inner workings of the apachectl graceful command and I can't seem to find the answer anywhere so maybe you can help. =20 Normally with a graceful the following happens. I issue a graceful. With strace I see something like this: stat64("/usr/local/apache/conf/sites/www.blah.com", {st_mode=3DS_IFREG|0644, st_size=3D680, ...}) =3D 0 open("/usr/local/apache/conf/sites/www.blah.com", O_RDONLY) =3D 4 fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D680, ...}) =3D 0 read(4, "ServerRoot /usr/local/apache\n###"..., 4096) =3D 680 stat64("/usr/local/apache", {st_mode=3DS_IFDIR|S_ISGID|0755, = st_size=3D4096, ...}) =3D 0 read(4, "", 4096) =3D 0 etc.etc. Then I see this: stat64("/usr/home/ws/blah/www.blah.com/www/", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D 0 etc.etc. =20 So my config is read and the DocumentRoots from the VHost are 'statted' on the disc. This process/pid is done rather quickly after which I see that this process terminates. During this time Apache functions fine! Next I can see with strace that the main Apache thread is "taking over". So in this case 25527. 25527 ? Ss 10:01 /usr/local/apache/bin/httpd -k start =20 5371 ? S 0:15 \_ /usr/local/apache/bin/httpd -k start =20 According to strace this happens: stat64("/usr/home/ws/blah/www.blah.nl/www/", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D 0 etc.etc. Apache is "statting" all the DocumentRoot directories on disk. This usually takes a long time and at this point Apache stops accepting new threads! This is really painful. =20 My question based on my observations are: I did a little research on the stat64 function and this seems to be a function that causes a lot of IO. From what I gather all extended file attributes for all dirs are processed. This seems like of lot of attributes. 1. It seems Apache does an stat64 of my DocumentRoots twice! Why? This doesn't make sense. First with the graceful command and next the Apache process itself. 2. Is there a way to get rid of stat64 or use a lighter/less intense stat function? 3. Further it seems when Apache is actually restarting/gracefulling that Apache stops accepting new threads. This isn't very convenient. What can I do about this? =20 I run my Apache server from a NFS storage mount. Statting files by querying their (extended) attributes is very costly/slow/inefficient. So I'm running into problems; are there ways to speed this up (apart from the obvious NFS and other filesystem optimizations I have done). I seems Apache is statting the directories because it wants to make sure it exists. But should I care whether a DocumentRoot from a Virtual Host exists? I've tested deleting directories and this doesn't crash Apache. So what's the reason behind this. =20 Hope someone can provide some insight. =20 Cheers. =20 Jan van den Berg =20 =20 =20 =20 ------_=_NextPart_001_01C74EB7.A3BB6EF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a couple of questions about the inner = workings of the apachectl graceful command and I can’t seem to find the = answer anywhere so maybe you can help.

 

Normally with a graceful the following = happens.

I issue a = graceful.

With strace I see something like = this:

stat64("/usr/local/apac= he/conf/sites/www.blah.com", {st_mode=3DS_IFREG|0644, st_size=3D680, ...}) =3D = 0

open("/usr/local/apache= /conf/sites/www.blah.com", O_RDONLY) =3D 4

fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D680, ...}) =3D = 0

read(4, = "ServerRoot /usr/local/apache\n###"..., 4096) =3D = 680

stat64("/usr/local/apac= he", {st_mode=3DS_IFDIR|S_ISGID|0755, st_size=3D4096, ...}) =3D = 0

read(4, = "", 4096)           &n= bsp;           =3D 0

etc.etc.

Then I see this:

        = ;    = stat64("/usr/home/ws/blah/www.blah.com/www/", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D = 0

etc.etc.

 

So my config is read and the DocumentRoots = from the VHost are ‘statted’ on the = disc.

This process/pid is done rather quickly after = which I see that this process terminates. During this time Apache functions = fine!

Next I can see with strace that the main = Apache thread is “taking over”. So in this case = 25527.

25527 ?        Ss    10:01 /usr/local/apache/bin/httpd -k start   =

 5371 ?        = S      0:15  \_ /usr/local/apache/bin/httpd -k = start

 

According to strace this = happens:

stat64("/usr/home/ws/bl= ah/www.blah.nl/www/", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D = 0

etc.etc.

Apache is “statting” all the = DocumentRoot directories on disk.

This usually takes a long time and at this = point Apache stops accepting new threads! This is really = painful.

 

My question based on my observations = are:

I did a little research on the stat64 function = and this seems to be a function that causes a lot of IO. From what I gather = all extended file attributes for all dirs are processed. This seems like of = lot of attributes.

1. It seems Apache does an stat64 of my = DocumentRoots twice! Why? This doesn’t make sense. First with the graceful = command and next the Apache process itself.

2. Is there a way to get rid of stat64 or use = a lighter/less intense stat function?

3. Further it seems when Apache is actually restarting/gracefulling that Apache stops accepting new threads. This = isn’t very convenient. What can I do about this?

 

I run my Apache server from a NFS storage = mount. Statting files by querying their (extended) attributes is very = costly/slow/inefficient. So I’m running into problems; are there ways to speed this up (apart = from the obvious NFS and other filesystem optimizations I have = done).

I seems Apache is statting the directories = because it wants to make sure it exists. But should I care whether a DocumentRoot = from a Virtual Host exists? I’ve tested deleting directories and this = doesn’t crash Apache. So what’s the reason behind = this.

 

Hope someone can provide some = insight.

 

Cheers.

 

Jan van den Berg

 

 

 

 

------_=_NextPart_001_01C74EB7.A3BB6EF8--