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.
