#mysql
19 October 2007
Total 26 pages. You are browsing page 2/26.
First :: Prev :: [1] [2] [3] [4] [5] [...] :: Next :: Last
00:22 <****> By the way it's innodb
00:22 <****> Are they equally loaded (or equally idle)? How warmed up were their caches when testing this?
00:23 <****> lol warmed up
00:23 <****> You can either test a query with a completely idle machine and a totally cold cache, which is likely to be the most reproducible as it requires real I/O, but needs a reboot between each test
00:24 <****> :O
00:24 <****> Or you can run an extended performance test of your application running loops of realistic load
00:24 <****> hummm
00:24 <****> im dizzy from staying up so many hours :(
00:24 <****> You can't do anything in between realistically
00:24 <****> just a single query tells you nothing if the caches/loads were different
00:24 <****> damnit my friend needs to hurry up and help me write this stupid documentation
00:25 <****> Is there a MySQL select option that has the same effect as Unix's "uniq"?
00:25 <****> MarkR42 but the diferrence is absurd.. alright?
00:25 <****> It is unscientific to compare a single select without the same conditions
00:26 <****> How warm the caches are contributes to performance so much, that if you don't know their state you can't compare
00:26 <****> MarkR42 if comparate the hardware... and both in 100% idle
00:27 <****> Are both machines totally idle with non-warmed up caches?
00:27 <****> And have identical (or at least similar) my.cnf ?
00:27 <****> MarkR42 i dont understand "non-warmed up caches"
00:27 <****> MarkR42 and identical my.cnf
00:27 <****> You can only compare any performance on a totally cold cache
00:27 <****> The only way on most OSs of getting a cold cache is a reboot
00:28 <****> MarkR42 only diference is the size of ibdata files..
00:28 <****> Anyway, you can answer some of my questions.. is the schema the same?
00:28 <****> MarkR42 ok... i reboot the dual xeon now....
00:28 <****> MarkR42 to test this...
00:30 <****> To do comparative performance testing you need the same conditions. If one machine was freshly loaded, the other has been worked on a lot, its data files are going to be differently structured. Restore them both from a virgin installation from the same mysqldump file
00:30 <****> Also bear in mind that dual CPUs will probably not benefit a single query
00:30 <****> Moreover, IO speed is almost certainly more relevant, especially if the caches are cold
00:31 <****> MarkR42 schema? how i see that?
00:31 <****> Oh dear
00:31 <****> MarkR42 sorry.. :)
00:31 <****> If you don't know how to see a schema, you're not in a good position to understand performance tuning
00:32 <****> The schema is the database structure; you should know it because you set it up, but moreover, you can dump it with mysqldump as recently discussed in this channel
00:32 <****> MarkR42 the databases is same... same dumpfile
00:32 <****> Ok, so if you restored the same dump, the schema will be the same, but the indexes may differ in structure if rows have been added/ removed from one but not the other
00:32 <****> MarkR42 uhm..
00:33 <****> MarkR42 no rows added/removed...
00:33 <****> Two CPUs will not benefit a single query from cold, it is likely to be 100% IO-bound anyway
00:33 <****>= day LIMIT 1
00:33 <****> or would it be faster to do
00:33 <****> SELECT balances.balance FROM balances WHERE balances.day SELECT MAX(b2.day) FROM balances as b2 WHERE b2.account_id = balances.account_id GROUP BY account_id)
00:33 <****> stfu
00:33 <****> w3?
00:34 <****> Sorry, just testing connection :P
00:34 <****> MarkR42 i understand... but theorical the dual xeon is faster then a sempron64 2300+
00:34 <****>= b2.day on the groupwise but you get the idea right?
00:34 <****> Not if it has slower IO
00:34 <****> For some reason I thought I was d/ced and wanted to say something to ensure a response :P
00:34 <****> NoFX_SBC: On a totally non-warmed up cache box, RAM is irrelevant and CPU speed is irrelevant, the only thing that matters is IO
00:35 <****> MarkR42 ok
00:35 <****> Do they have similar performance IO or is the newer machine better, or what?
00:35 <****> If the discs are in hardware RAID, that will significantly affect its performance, but I'm not sure how
00:36 <****> You may find that an older box with a non-raid disc actually does faster io
00:36 <****> w3: /msg SQL help
00:36 <****> Having said that, IO does not typically vary by 20x
00:36 <****> SQL will always talk to anyone
00:36 <****> MarkR42 i not use raid
00:37 <****> Are you sure you're comparing these querys in the same context? are both boxes totally cold and idle when you compare them?
00:37 <****> I mean, cold caches, nothing else on the box.
00:38 <****> If the older machine has accessed the table recently, it is likely that it is still in disc cache, which is typically loads faster than disc
00:38 <****> MarkR42 yeap, only me using theres machines... and 100% idle before i run the query
00:39 <****> And rebooted before you ran the query in each case?
00:39 <****> MarkR42 no... i not rebooted both machines...
00:40 <****> In which case it is not fair
00:40 <****> If one cache is warm, the other is cold, it's not a good comparison
00:40 <****> MarkR42 one question: the difference into 32bits and 64bits probably cause of that?
00:41 <****> In any case, what's the use of one query?
00:41 <****> It should not
00:41 <****> More likely caching
00:41 <****> hi all; if i set up a foreign key constraint does mysql5 automatically index that field or do i need to add manually?
00:41 <****> Most of mysql's performance is, in practice, bottlenecked by hardware either disc or network
00:41 <****> MarkR42 that query is used by a java application using hibernate and c3p0
00:42 <****> I've no idea what they are; you might want to benchmark the query alone if possible
00:43 <****> hibernate is orm; c3p0 is connection pooling
00:43 <****> MarkR42 i understand...
00:44 <****> I would say in general however, that the performance of a single query on a one-off basis is no basis for a comparison
00:44 <****> Perform a general whole end-to-end performance test of your software stack
00:44 <****> With the old machine vs the new one
00:44 <****> Run it for a long time, i.e. soak test, if possible
00:44 <****> especially when used through one or more libraries? :)
00:45 <****> MarkR42 u recomend i reboot both servers and run the same query?
00:45 <****> to ensure that caches have long enough to get full, and that the data are large enough to fill ram etc
00:45 <****> I would recommend you try rebooting both servers and running a single query, from the CLI, before doing anything else to either of them
00:45 <****> MarkR42 ok, i try that now..
00:45 <****> That would certainly ensure that that query is IO bound
00:45 <****> but I'm not sure how useful the result would be
00:45 <****> (even if it's fair)
00:46 <****> Because in production, servers rarely get rebooted, and more than one query is the norm
00:47 <****> got to sleep, goodnight
00:57 <****> Ok
00:57 <****> mysqld will not star
00:57 <****> t
00:57 <****> I am on Debian Linux, where will errors be logged
00:58 <****> ?
00:58 <****> syslog
00:59 <****> syslog seems empty
00:59 <****> thats not good
00:59 <****> BTW, it got removed and re-put there
00:59 <****> are you root?
Total 26 pages. You are browsing page 2/26.
First :: Prev :: [1] [2] [3] [4] [5] [...] :: Next :: Last