Re: [firebird-support] Re: Bad surprise on performance
Thank you very much for the advice, Hannes. I did not think of this too well. But of course this sounds very logical. I will re-configure the server to match the most popular database page size (I have 6 different databases). I will first consult different papers I have from conferences and some available other documentation, and then decide what will be a good page size for my scenario after the migration. thanks, André = Ihre Nachricht: Guten Tag André Knappstein knappst...@beta-eigenheim.de [firebird-support], am Samstag, 3. Januar 2015 um 10:45 schrieben Sie: Stripe size is 64K, btw. much too big , best size for a stripset ist same as DB Page Size Strip Set 64Kb means that the controller will read and write Blocks of 64KB each I/O operation with a page size of 4 KB 60 KB are moved around with no use , wasting more then 90 percent of the disk read/write bandwidth (disk caches will reduce the impact somewhat) my LSI Controller allows me a stripeset as small as 16kb , so it set my page size to match
[firebird-support] Re: Bad surprise on performance
03.01.2015 03:08, André Knappstein wrote: I created a test table on both old and new server to play with updates and inserts (~ 150.000 records) Performance with 2.5.3 x64 on Win2008 is constantly changing, but at best its some 8 seconds and worst even 2 minutes! Performance with 1.5.4 x86 on Win2003 is always about the same, and always 2.9 - 3.2 seconds. Are servers (especially the new one) loaded when you perform your tests? Execution time can sometimes vary in SS due to the GC policy but it cannot happen for CS, unless there are other queries running at the same time. Query update X3058000 x set x.p3058_004n = (x.p3058_004n * 2) Operations (new Server) Read : 2.247 Writes : 5.960 Fetches: 2.476.240 Marks : 807.922 Operations (old Server) Read : 8.516 Writes : 6.084 Fetches: 1.602.243 Marks : 582.584 These numbers suggest that either databases contain different data or you're comparing SS vs CS, possibly with some concurrent activity. Dmitry ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) * To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com * Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: Bad surprise on performance
Thank you Dmitry. Seems I found the solution to the real problem parallel to your posting of the message (BBU failure report resetting cache parameters). The difference on old hardware (2.9 - 3.2) seconds probably is due to inaccuracy in the very simple test methods. And, yes, nobody was currently working on the old hardware, but there still are some 400 fb_inet processes active, which probably added to the inaccuracy. = Ihre Nachricht: 03.01.2015 03:08, André Knappstein wrote: I created a test table on both old and new server to play with updates and inserts (~ 150.000 records) Performance with 2.5.3 x64 on Win2008 is constantly changing, but at best its some 8 seconds and worst even 2 minutes! Performance with 1.5.4 x86 on Win2003 is always about the same, and always 2.9 - 3.2 seconds. Are servers (especially the new one) loaded when you perform your tests? Execution time can sometimes vary in SS due to the GC policy but it cannot happen for CS, unless there are other queries running at the same time. Query update X3058000 x set x.p3058_004n = (x.p3058_004n * 2) Operations (new Server) Read : 2.247 Writes : 5.960 Fetches: 2.476.240 Marks : 807.922 Operations (old Server) Read : 8.516 Writes : 6.084 Fetches: 1.602.243 Marks : 582.584 These numbers suggest that either databases contain different data or you're comparing SS vs CS, possibly with some concurrent activity. Dmitry ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) * To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com * Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: Bad surprise on performance
Operations (new Server) Read : 2.247 Writes : 5.960 Fetches: 2.476.240 Marks : 807.922 Operations (old Server) Read : 8.516 Writes : 6.084 Fetches: 1.602.243 Marks : 582.584 These numbers suggest that either databases contain different data or you're comparing SS vs CS, possibly with some concurrent activity. Absolutely the same data in both databases, both definitely on CS. Table specifically created for testing with absolutely the same records and subsequent identical DML commands and commit intervals. Will repeat the same test later, now with re-configured RAID cache. Right now my wonderful wife is already tapping her foot to signal the start of a shopping tour. And, trust me, this can be more dangerous than an inefficient FB server ;-) ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) * To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com * Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: Bad surprise on performance
Guten Tag André Knappstein knappst...@beta-eigenheim.de [firebird-support], am Samstag, 3. Januar 2015 um 10:45 schrieben Sie: Stripe size is 64K, btw. much too big , best size for a stripset ist same as DB Page Size Strip Set 64Kb means that the controller will read and write Blocks of 64KB each I/O operation with a page size of 4 KB 60 KB are moved around with no use , wasting more then 90 percent of the disk read/write bandwidth (disk caches will reduce the impact somewhat) my LSI Controller allows me a stripeset as small as 16kb , so it set my page size to match -- Mit freundlichen Grüssen/ wbr Hannes Streicher
Re: [firebird-support] Re: Bad surprise on performance
Hello Vlad, It is sure Raid 0 with 3 * 600 GB Toshiba SAS. I only installed the server today. I did not use the LSI Raid BIOS for configuration but the server view installation kit from the producer. So I will have to look up stripe size and BBU status. Next week I will also apply a benchmark test and then write results here.Iwill also try on other hardware. I have 2 other new servers for other uses but so far still idle, so I can play a bit. I wanted to drop you a message anyway, because if I understood correctly in Prague you do not have too many different hardware systems for testing, somaybe if you have a test database and a prepared benchmark I can run some tests with FB 3. Hi, André ! [Old] Server 2003 x86 no service packs Xeon with 4 GB RAM Classic 1.5.4 (x86, of course) Raid 0 on 2 * 500 GB SAS (though this is from memory, I should look it up...) [new] Server 2008 R2 x64 SP1 Xeon with 8 GB RAM (I will shortly add +8) Classic 2.5.3 x64 Raid 0 on 3 * 600 GB SAS Raid 0 ? Are you sure ? In comparison to what I read from others, my databases are small. Biggest database is some 1 GB only. Agree, it is small database. Bad performance on updates and inserts and extremely bad performance on committing a big number of record changes (~ 150.000 updates). It points us to the issues with writes or with random writes. It could be interesting to see results of disk IO benchmark (any you like which able to test random writes). Also it is good to know some raid settings such as stripe\block size, write cache mode, presence of BBU (battery for internal cache). Regards, Vlad
[firebird-support] Re: Bad surprise on performance
Hi, André ! [Old] Server 2003 x86 no service packs Xeon with 4 GB RAM Classic 1.5.4 (x86, of course) Raid 0 on 2 * 500 GB SAS (though this is from memory, I should look it up...) [new] Server 2008 R2 x64 SP1 Xeon with 8 GB RAM (I will shortly add +8) Classic 2.5.3 x64 Raid 0 on 3 * 600 GB SAS Raid 0 ? Are you sure ? In comparison to what I read from others, my databases are small. Biggest database is some 1 GB only. Agree, it is small database. Bad performance on updates and inserts and extremely bad performance on committing a big number of record changes (~ 150.000 updates). It points us to the issues with writes or with random writes. It could be interesting to see results of disk IO benchmark (any you like which able to test random writes). Also it is good to know some raid settings such as stripe\block size, write cache mode, presence of BBU (battery for internal cache). Regards, Vlad
