Performance Tests

[Stephan Böni]

Perhaps nice to know: We've made a lot performance tests (disk i/o related) with an OpenSSI 1.9.2 (SUSE) cluster containing 4 nodes IBM x336 with each 1 Xen 3 GHz CPU / 4 GB RAM and one IBM DS4300 storage system attached over fibre channel with 8 RAID5 FC-Disks. Here are the results:

 

- One system as single system has a good r/w performance.

- One system as single node OpenSSI cluster (not usable) has a terrible r/w performance.

- Two systems (nodes) in a OpenSSI cluster have a good read but still a terrible write performace.

- 3 and 4 nodes are not better than 2 nodes on r/w performance.

 

On heavy load OpenSSI crashs sometimes. The disk write performance is so terrible, that my old PC with an ide disk is faster. :-(

Perhaps that could be faster with GFS.

 

Stephan

 

[Ivan Krstić-3]

Stephan Böni wrote:
> - One system as single node OpenSSI cluster (not usable) has a terrible
> r/w performance.

This is interesting.

> - 3 and 4 nodes are not better than 2 nodes on r/w performance.

Well, assuming a standard CFS-stacked root filesystem is in question,
the performance can't increase with the addition of nodes, only degrade,

> On heavy load OpenSSI crashs sometimes.

This is a known issue with 1.9.1, but I think Roger was hoping it was
fixed in 1.9.2. Can you recreate the problem and send us a backtrace of
the oops/panic?

Thanks for reporting this!

--
Ivan Krstic <krstic@...> | 0x147C722D


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[John Hughes]

Stephan Böni wrote:

> - One system as single node OpenSSI cluster (not usable) has a
> terrible r/w performance.
> - Two systems (nodes) in a OpenSSI cluster have a good read but still
> a terrible write performace.

Do you have failover?  Are you using "chard"?




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[Roger Tsang]

On 12/19/05, Stephan Böni <boeni@...> wrote:

>
> Perhaps nice to know: We've made a lot performance tests (disk i/o related)
> with an OpenSSI 1.9.2 (SUSE) cluster containing 4 nodes IBM x336 with each 1
> Xen 3 GHz CPU / 4 GB RAM and one IBM DS4300 storage system attached over
> fibre channel with 8 RAID5 FC-Disks. Here are the results:
>
> - One system as single system has a good r/w performance.
> - One system as single node OpenSSI cluster (not usable) has a terrible r/w
> performance.
> - Two systems (nodes) in a OpenSSI cluster have a good read but still a
> terrible write performace.
> - 3 and 4 nodes are not better than 2 nodes on r/w performance.
>
> On heavy load OpenSSI crashs sometimes. The disk write performance is so
> terrible, that my old PC with an ide disk is faster. :-(
> Perhaps that could be faster with GFS.
>
> Stephan
>

This is what I'm getting on FC3 SSI-1.9.2 preview AMD64 3000+ nodes
with 2GB RAM each with IDE disks (not raided).  Running the tests at
the CFS server on DRBD storage (procotol C) with Gigabit ICS (MTU
1500) and the filesystem is ext3 (rw,noatime,chard) with failover
enabled.  Default /proc/sys/vm knobs.

The following is just to give an idea, since there is a certain level
of buffering going on here.

        Iozone: Performance Test of File I/O
                Version $Revision: 3.226 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million,
                     Jean-Marc Zucconi, Jeff Blomberg,
                     Erik Habbinga, Kris Strecker.

        Run began: Mon Dec 19 19:28:52 2005

        Auto Mode
        File size set to 81920 KB
        Command line used: /opt/iozone/bin/iozone -a -s 80m
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random
random    bkwd  record  stride
              KB  reclen   write rewrite    read    reread    read  
write    read rewrite    read   fwrite frewrite   fread  freread
           81920       4  592283  619564   988083   980068  878961  
20679  941683 1586735  898274   548708   592566 1013722  1011595
           81920       8  667475  696829  1150625  1187178 1076745  
29790  960869 1083355 1059753   620187   658304 1138362  1167036
           81920      16  698469  719081  1375325  1385189 1290629  
35736 1309778 1360550  603942   115238   449226 1201207   537780
           81920      32  419373  695628  1425044   554109 1414509  
16313 1423036 2156929 1372745   678662   495718 1323854  1420667
           81920      64  722640  434416  1421208  1353176 1290444  
17924 1323576 1510463 1341103   221657   281032 1290404   998561
           81920     128  684029  781753  1293133  1301826 1327970  
37276 1300853 1603821 1312924   628143   654124 1319672  1317889
           81920     256  681287  714472  1061937  1091101 1113102  
36389  981677 1061138 1081709   326928   482651 1125198  1138187
           81920     512  363705  365272   720733   738417  735018  
37955  721412  632064  713837   417016   396106  709902   562062
           81920    1024  365789  358002   739383   728818  732717  
43929  732887  581319  726994   424326   444714  735659   412643
           81920    2048  571919  590733   425885   712323  719789  
44347  697946  670611  718332   294249   447814  674666   738364
           81920    4096  559207  591715   730456   730619  739503
109754  736915  673545  727609   428350   325316  669850   694349
           81920    8192  559704  589009   742150   729338  723188
102824  742553  663567  714036   445961   474620  744605   730358
           81920   16384  348019  595041   735355   404941  739103  
43135  418527  664757  653248   425461   471821  649071   361038

iozone test complete.

Roger


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[Walker, Bruce J (HP-Labs)]

Performance numbers would be most useful if done as a comparison (say base vs. single node CFS or CFS server node vs. non-server node; chard vs. non chard, etc.).  We could then identify which areas need work (CFS stacked on ext3 or remote CFS;  large reads vs. small writes, etc.).

Bruce


-----Original Message-----
From: ssic-linux-users-admin@... [mailto:ssic-linux-users-admin@...] On Behalf Of Roger Tsang
Sent: Monday, December 19, 2005 4:45 PM
To: Stephan Böni
Cc: ssic-linux-users@...
Subject: Re: [SSI-users] Performance Tests

On 12/19/05, Stephan Böni <boeni@...> wrote:

>
> Perhaps nice to know: We've made a lot performance tests (disk i/o
> related) with an OpenSSI 1.9.2 (SUSE) cluster containing 4 nodes IBM
> x336 with each 1 Xen 3 GHz CPU / 4 GB RAM and one IBM DS4300 storage
> system attached over fibre channel with 8 RAID5 FC-Disks. Here are the results:
>
> - One system as single system has a good r/w performance.
> - One system as single node OpenSSI cluster (not usable) has a
> terrible r/w performance.
> - Two systems (nodes) in a OpenSSI cluster have a good read but still
> a terrible write performace.
> - 3 and 4 nodes are not better than 2 nodes on r/w performance.
>
> On heavy load OpenSSI crashs sometimes. The disk write performance is
> so terrible, that my old PC with an ide disk is faster. :-( Perhaps
> that could be faster with GFS.
>
> Stephan
>

This is what I'm getting on FC3 SSI-1.9.2 preview AMD64 3000+ nodes with 2GB RAM each with IDE disks (not raided).  Running the tests at the CFS server on DRBD storage (procotol C) with Gigabit ICS (MTU
1500) and the filesystem is ext3 (rw,noatime,chard) with failover enabled.  Default /proc/sys/vm knobs.

The following is just to give an idea, since there is a certain level of buffering going on here.

        Iozone: Performance Test of File I/O
                Version $Revision: 3.226 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million,
                     Jean-Marc Zucconi, Jeff Blomberg,
                     Erik Habbinga, Kris Strecker.

        Run began: Mon Dec 19 19:28:52 2005

        Auto Mode
        File size set to 81920 KB
        Command line used: /opt/iozone/bin/iozone -a -s 80m
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random
random    bkwd  record  stride
              KB  reclen   write rewrite    read    reread    read  
write    read rewrite    read   fwrite frewrite   fread  freread
           81920       4  592283  619564   988083   980068  878961  
20679  941683 1586735  898274   548708   592566 1013722  1011595
           81920       8  667475  696829  1150625  1187178 1076745  
29790  960869 1083355 1059753   620187   658304 1138362  1167036
           81920      16  698469  719081  1375325  1385189 1290629  
35736 1309778 1360550  603942   115238   449226 1201207   537780
           81920      32  419373  695628  1425044   554109 1414509  
16313 1423036 2156929 1372745   678662   495718 1323854  1420667
           81920      64  722640  434416  1421208  1353176 1290444  
17924 1323576 1510463 1341103   221657   281032 1290404   998561
           81920     128  684029  781753  1293133  1301826 1327970  
37276 1300853 1603821 1312924   628143   654124 1319672  1317889
           81920     256  681287  714472  1061937  1091101 1113102  
36389  981677 1061138 1081709   326928   482651 1125198  1138187
           81920     512  363705  365272   720733   738417  735018  
37955  721412  632064  713837   417016   396106  709902   562062
           81920    1024  365789  358002   739383   728818  732717  
43929  732887  581319  726994   424326   444714  735659   412643
           81920    2048  571919  590733   425885   712323  719789  
44347  697946  670611  718332   294249   447814  674666   738364
           81920    4096  559207  591715   730456   730619  739503
109754  736915  673545  727609   428350   325316  669850   694349
           81920    8192  559704  589009   742150   729338  723188
102824  742553  663567  714036   445961   474620  744605   730358
           81920   16384  348019  595041   735355   404941  739103  
43135  418527  664757  653248   425461   471821  649071   361038

iozone test complete.

Roger


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?  Stop!  Download the new AJAX search engine that makes searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[Roger Tsang]

Just to follow up here is the same test on the non-server node (remote
CFS).  Again don't trust the numbers too much because technically I'm
suppose to use >2GB filesize and perform the test on a completely idle
cluster.  However this quick test shows remote CFS isn't that much
slower, only about 10% performance hit (random write).

Roger

        Iozone: Performance Test of File I/O
                Version $Revision: 3.226 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million,
                     Jean-Marc Zucconi, Jeff Blomberg,
                     Erik Habbinga, Kris Strecker.

        Run began: Mon Dec 19 22:40:20 2005

        Auto Mode
        File size set to 81920 KB
        Command line used: /opt/iozone/bin/iozone -a -s 80m
        Output is in Kbytes/sec
        Time Resolution = 0.000004 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random
random    bkwd  record  stride
              KB  reclen   write rewrite    read    reread    read  
write    read rewrite    read   fwrite frewrite   fread  freread
           81920       4  491271  586567   979401   976586  821334  
18933  884864  976236  843284   542901   564797  915359   964593
           81920       8  633981  659937  1151045  1140185 1032896  
23723 1087813 1779746 1064530   580692   645501 1128826  1122992
           81920      16  690509  729988  1326294  1360889 1240646  
28026 1261043 2204226 1236619   632381   638911 1310363  1325887
           81920      32  708104  744037  1423653  1411635 1375280  
30391 1405938 1374313 1385913   604085   682928 1375375  1397859
           81920      64  703973  738829  1417445  1458143 1392864  
33424 1367702 1532588 1397475   648373   665854 1433970  1440479
           81920     128  700511  735129  1434398  1423806 1414730  
32349 1350943 1578934 1422199   572542   593971 1395354  1417915
           81920     256  633531  670864  1170535  1190837 1170237  
32266 1164280 1163437 1164531   447479   470818 1181578  1188278
           81920     512  561045  572663   604794   549193  701507  
33016  735632  670925  715246   411082   430946  727997   739918
           81920    1024  558007  584178   704773   733064  734425  
37524  698744  638299  633884   295330   437393  731951   731767
           81920    2048  559218  586189   743806   744719  735704  
40197  741779  670480  750292   421787   442586  740921   732055
           81920    4096  537194  578706   748893   752305  758601
105317  752284  654673  746179   359526   452458  740666   742310
           81920    8192  561796  593038   740808   741029  733773  
94732  736444  654135  710303   436946   466015  753696   750224
           81920   16384  543488  583109   729150   743415  740164  
38855  738670  638224  726382   401824   411224  760871   757235

iozone test complete.


On 12/19/05, Roger Tsang <roger.tsang@...> wrote:

>
> This is what I'm getting on FC3 SSI-1.9.2 preview AMD64 3000+ nodes
> with 2GB RAM each with IDE disks (not raided).  Running the tests at
> the CFS server on DRBD storage (procotol C) with Gigabit ICS (MTU
> 1500) and the filesystem is ext3 (rw,noatime,chard) with failover
> enabled.  Default /proc/sys/vm knobs.
>
> The following is just to give an idea, since there is a certain level
> of buffering going on here.
>
>         Iozone: Performance Test of File I/O
>                 Version $Revision: 3.226 $
>                 Compiled for 32 bit mode.
>                 Build: linux
>
>         Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
>                      Al Slater, Scott Rhine, Mike Wisner, Ken Goss
>                      Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
>                      Randy Dunlap, Mark Montague, Dan Million,
>                      Jean-Marc Zucconi, Jeff Blomberg,
>                      Erik Habbinga, Kris Strecker.
>
>         Run began: Mon Dec 19 19:28:52 2005
>
>         Auto Mode
>         File size set to 81920 KB
>         Command line used: /opt/iozone/bin/iozone -a -s 80m
>         Output is in Kbytes/sec
>         Time Resolution = 0.000001 seconds.
>         Processor cache size set to 1024 Kbytes.
>         Processor cache line size set to 32 bytes.
>         File stride size set to 17 * record size.
>                                                             random
> random    bkwd  record  stride
>               KB  reclen   write rewrite    read    reread    read
> write    read rewrite    read   fwrite frewrite   fread  freread
>            81920       4  592283  619564   988083   980068  878961
> 20679  941683 1586735  898274   548708   592566 1013722  1011595
>            81920       8  667475  696829  1150625  1187178 1076745
> 29790  960869 1083355 1059753   620187   658304 1138362  1167036
>            81920      16  698469  719081  1375325  1385189 1290629
> 35736 1309778 1360550  603942   115238   449226 1201207   537780
>            81920      32  419373  695628  1425044   554109 1414509
> 16313 1423036 2156929 1372745   678662   495718 1323854  1420667
>            81920      64  722640  434416  1421208  1353176 1290444
> 17924 1323576 1510463 1341103   221657   281032 1290404   998561
>            81920     128  684029  781753  1293133  1301826 1327970
> 37276 1300853 1603821 1312924   628143   654124 1319672  1317889
>            81920     256  681287  714472  1061937  1091101 1113102
> 36389  981677 1061138 1081709   326928   482651 1125198  1138187
>            81920     512  363705  365272   720733   738417  735018
> 37955  721412  632064  713837   417016   396106  709902   562062
>            81920    1024  365789  358002   739383   728818  732717
> 43929  732887  581319  726994   424326   444714  735659   412643
>            81920    2048  571919  590733   425885   712323  719789
> 44347  697946  670611  718332   294249   447814  674666   738364
>            81920    4096  559207  591715   730456   730619  739503
> 109754  736915  673545  727609   428350   325316  669850   694349
>            81920    8192  559704  589009   742150   729338  723188
> 102824  742553  663567  714036   445961   474620  744605   730358
>            81920   16384  348019  595041   735355   404941  739103
> 43135  418527  664757  653248   425461   471821  649071   361038
>
> iozone test complete.
>
> Roger
>

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[Stephan Böni]

> > Stephan Böni wrote:
> > - One system as single node OpenSSI cluster (not usable) has a
> > terrible r/w performance.
> > - Two systems (nodes) in a OpenSSI cluster have a good read
> > but still a terrible write performace.
>
> John Hughes [mailto:john@...] wrote:
> Do you have failover?  Are you using "chard"?

No failover. ext3 as root filesystem and reiserfs as data filesystem. The interconnection between the nodes is a separte GBit-LAN, but only on one single node the performance is poor (and on both filesystem types). I think it's a problem of CFS.

Stephan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[Stephan Böni]

> Ivan Krstic [mailto:krstic@...] wrote:
>
> > Stephan Böni wrote:
> > - One system as single node OpenSSI cluster (not usable)
> >   has a terrible r/w performance.
>
> This is interesting.
>
> > - 3 and 4 nodes are not better than 2 nodes on r/w performance.
>
> Well, assuming a standard CFS-stacked root filesystem is in question,
> the performance can't increase with the addition of nodes,
> only degrade,
>
> > On heavy load OpenSSI crashs sometimes.
>
> This is a known issue with 1.9.1, but I think Roger was hoping it was
> fixed in 1.9.2. Can you recreate the problem and send us a
> backtrace of the oops/panic?

The cluster has freezed, no error messages, nothing.  :-(

Stephan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[Roger Tsang]

Hi Stephan,

Just out of curiosity can you try your performance tests again but
with chard mounts?  Also what is the performance without CFS layer
while running the OpenSSI kernel?

Roger


On 12/20/05, Stephan Böni <boeni@...> wrote:

>
> > Ivan Krstic [mailto:krstic@...] wrote:
> >
> > > Stephan Böni wrote:
> > > - One system as single node OpenSSI cluster (not usable)
> > >   has a terrible r/w performance.
> >
> > This is interesting.
> >
> > > - 3 and 4 nodes are not better than 2 nodes on r/w performance.
> >
> > Well, assuming a standard CFS-stacked root filesystem is in question,
> > the performance can't increase with the addition of nodes,
> > only degrade,
> >
> > > On heavy load OpenSSI crashs sometimes.
> >
> > This is a known issue with 1.9.1, but I think Roger was hoping it was
> > fixed in 1.9.2. Can you recreate the problem and send us a
> > backtrace of the oops/panic?
>
> The cluster has freezed, no error messages, nothing.  :-(
>
> Stephan
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&opclick
> _______________________________________________
> Ssic-linux-users mailing list
> Ssic-linux-users@...
> https://lists.sourceforge.net/lists/listinfo/ssic-linux-users
>

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[John Hughes]

Stephan Böni wrote:

>>>Stephan Böni wrote:
>>>- One system as single node OpenSSI cluster (not usable) has a
>>>terrible r/w performance.
>>>- Two systems (nodes) in a OpenSSI cluster have a good read
>>>but still a terrible write performace.
>>>      
>>>
>>John Hughes [mailto:john@...] wrote:
>>Do you have failover?  Are you using "chard"?
>>    
>>
>
>No failover. ext3 as root filesystem and reiserfs as data filesystem. The interconnection between the nodes is a separte GBit-LAN, but only on one single node the performance is poor (and on both filesystem types). I think it's a problem of CFS.
>
>  
>

Interesting.

How are you mesuring performance.

How big is the difference between standard kernel and OpenSSI kernel?

Which non-ssi kernel are you using?



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users

[Stephan Böni]

>
> >>>Stephan Böni wrote:
> >>>- One system as single node OpenSSI cluster (not usable) has a
> >>>terrible r/w performance.
> >>>- Two systems (nodes) in a OpenSSI cluster have a good read
> >>>but still a terrible write performace.
> >>>      
> >>>
> >>John Hughes [mailto:john@...] wrote:
> >>Do you have failover?  Are you using "chard"?
> >>    
> >Stephan Böni wrote:
> >
> >No failover. ext3 as root filesystem and reiserfs as data
> filesystem. The interconnection between the nodes is a
> separte GBit-LAN, but only on one single node the performance
> is poor (and on both filesystem types). I think it's a problem of CFS.
> >
>
> John Hughes [mailto:john@...] wrote:
>
> Interesting.
>
> How are you mesuring performance.

It's an own performance test application within a database system. (Intersystems Caaché)

> How big is the difference between standard kernel and OpenSSI kernel?

The OpenSSI kernel is 2,5 x slower than a standard kernel
 
> Which non-ssi kernel are you using?

2.6.8-24.19-bigsmp (SUSE 9.2)

Stephan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Ssic-linux-users mailing list
Ssic-linux-users@...
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users