Rob Kampen wrote: > > > nate wrote: >> Rob Kampen wrote: >> >> >>> How do I get some extra log info to track this down? >>> >> >> Have you tried to run 'show full processlist' on mysql while >> the query is running? It should show all active queries, what >> they are doing and how long they have been running for. >> >> Also enable slow query logging and logging when not using >> indexes, add to /etc/my.cnf and restart mysql: >> >> example: >> log-slow-queries = /var/lib/mysql_logs/slowqueries.log >> log-queries-not-using-indexes >> long_query_time = 3 >> >> nate >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > Have entered those into the my.cnf file, restarted mysqld and > monitored the file - no entries forthcoming with the faulty page request. > looking at show full processlist, I see the start of a new process, > then almost immediately it goes to sleep and then just sits there.... > Thanks for these items Nate - look useful for the future. > I think I need to look in the php direction.... > Rob > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > Found the issue - in the php we are doing a strtotime() call and we did not have the date.timezone setup, thus for every call to this function it was calling the error reporting code and dumping all the stack trace data, thus using up 30 seconds and timing out. Thanks all for your comments and help Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: rkampen.vcf Type: text/x-vcard Size: 121 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20090121/8b7fb2a8/attachment-0005.vcf>