| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13
Comments:
<0> you might not actually want to use insert delayed
<0> sometimes it hurts performance
<0> somewhat counterintuitively
<1> seems weird, but yeah I've tried w/o delayed and it's actually about the same for performance
<2> multifarious- which crash courses ? any url's please
<1> the performance of the application is ok, but the problem is really more of a system impact
<1> cpu spikes pretty much continually
<1> so it makes me hesitant to put this sort of code into the wild
<0> do you knwo what's causing the spikes?
<1> the thread that has been blessed to be the mysql thread is pretty simple
<1> it gets data from a queue, parses it into a query, and inserts it into the database
<1> so really the only thing that it does is mysql_real_query
<1> which is my only suspect at the moment
<0> and it's that thread that spikes?
<1> so either mysql_real_query is expensive and 1) I'm not using it the "right" way or 2) there is a better way than mysql_real_query
<1> If I comment out the mysql real query then the cpu utilization goes to nill
<0> sweet.
<1> yes, absolutely
<1> so anyone? buller?
<1> 32 inserts a second... what's the best way?
<0> if it's all in one connection use the prepared statement api
<0> if it's all into one table and it's myisam make sure it can take advantage of concurrent inserts
<1> does real_query make things magically concurrent... or would I have more than one insert thread to take advantage?
Return to
#mysql
or
Go to some related
logs:
CONFIG_HZ ntpd -crazy
#math
#gentoo
SimpleHTTPServer.test
de_train tactics
ubuntu linux firewire prolific
liveusb gentoo windows
sdl_ttf devpak
nautilus screensaverr
#perl
|
|