On May 7, 2007, at 2:01 PM, Perrin Harkins wrote:
It does when you shut down the BDB "environment", but there's no reason to do that unless your processes are exiting.
ah, that makes sense. so long as one process has bdb running, its there's a shared bdb memory section.
Blocking? You mean readers blocking writers? If you have frequent updates, the MVCC model used by InnoDB tables avoids that. In general, I've found the read performance of InnoDB to be better than MyISAM in my application.
readers blocking readers.
they eventually realized that when the system wasn't making use of the mysql query caching, the requests were blocking with all the other mysql traffic. i think it was because all the selects happen in one synchronous process.Not sure what you're talking about there. MySQL is a multi-threaded daemon and readers don't block each other, even with the simple MyISAM locking scheme. In any case, the scenario I had in mind for Will Fould's situation is a dedicated MySQL on the local box that does nothing but handle this shared data.
Is this new?I thought the same as you , until that lighttpd posting ( March 2006 ). But according to Jan , who was at MySQL at the time , MySQL only had a synchronous API. An async was on a todo list, but selects were blocking on the whole server.
I didn't really look into it much then, because I was already converted to Postgres for just about everything at the time.
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.