Server Version: Apache/1.3.19 (Unix) PHP/4.0.4pl1 MySQL 3.23.33 To find out about a peculiar phenomenon I am hunting for 10 days already, I added a stopwatch and record for each URL the elapsed time from entry of page construction to end. Right from the start, I get significant data: auto Timestamp URL secs 178 20010727193459 Preis/30-35 1.06 179 20010727193459 Preis/35-40 0.41 180 20010727193500 Preis/18-20 81.55 181 20010727193505 Preis/40-45 0.81 182 20010727193505 Anzeigen/Woche/9 2.68 183 20010727193526 1461 0.47 184 20010727193531 Preis/20-25 91.86 185 20010727193538 4485 0.17 186 20010727193549 Berichte/120 0.56 Entries 180 and 184 are extreme. All Preis-URLs fetch classifieds within that price range (horses 30.000-35.000 DM, for example). As can be seen from the timestamp alone, this is no human scanning the pages, rather a spider. The program is always the same, the table also, the only difference are the conditioning numbers for the query. Therefore, it is not likely to be a program or query fault, as this should produce equally bad figures on all URLs with that pattern. The table in question for the above data is ok, as might be suspected, because it is the same table with all queries, slow or fast. I just made a manual test with URL Preis/18-20: it took 2.98 seconds - so this is proof that it is not the data range that produces the differences. I show at most 10 records, and clearly there will be more in this range than in range 40-45 (in fact, we have no offers in this range right now). Time is consumed not in fetching the data but in producing the html for presenting the data. Did anybody ever see something like this? Should I upgrade to 3.23.40? Is it plausible that this is a problem with MySQL in the first place? Any places to look at in addition? Any ideas of how to track this thing down? What else can I say? When watching top, things go nicely for a while. If there is high load, it is significant that mostly httpd processes are shown, very seldom a mysql process. All of a sudden, the picture changes. Some mysql processes show with status column showing D instead of R, meaning "uninterruptible sleep" versus "running". Looking at processlist, I may or may not see mysql processes. If I do, there are all kinds of status reports like sorting, opening, copying to tmp table etc. Without that state, I have little chance to see any processes at all (except root looking for processlist :-)), which seems to show that mysql is extremely fast. With these few mysql processes in status D, very fast some httpd processes show status D as well, and in addition, if there were many processes running and showing before, we have only a few shown with status D and few if any running. So if I let top run in the background without really watching, I will notice this change by the number of rows shown. Response time will decline very fast, load average will rise instead, and we have seen values of up to 200, at which situation the machine is essentially non responding to anything. The only remedy we know to date is killing and restarting Apache, which we do with a cron job every minute evaluating load average, but that's just a workaround for the moment. We will refine this watching for status D. I thought about bad queries or faulty code, but the data above does not back this idea. Also, we thought that the machine could not handle the load, but it happens with few hits as well and does not seem to accelerate significantly with heavy load. Actually, I don't know if the data shown above relates to Status D or not, but it is highly peculiar in any case and maybe significant. These are the first data that really show something weird. I have processlist and Apache status, but neither showed anything valuable. -- Herzlich Werner Stuerenburg _________________________________________________ ISIS Verlag, Teut 3, D-32683 Barntrup-Alverdissen Tel 0(049) 5224-997 407 · Fax 0(049) 5224-997 409 http://pferdezeitung.de --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
