Olio on 6-core Opterons (Istanbul) based Sun Systems

Sun is launching systems with multisocket  6-core Opterons (Istanbul) today. Last week I got access to  Sun Fire X4140 with 2 x 6-core Opterons with 36GB RAM. It is always great to see such a 1RU system packaged with so many x64 cores.

# psrinfo -vp
The physical processor has 6 virtual processors (0-5)
  x86 (chipid 0x0 AuthenticAMD family 16 model 8 step 0 clock 2600 MHz)
    Six-Core AMD Opteron(tm) Processor 8435
The physical processor has 6 virtual processors (6-11)
  x86 (chipid 0x1 AuthenticAMD family 16 model 8 step 0 clock 2600 MHz)
    Six-Core AMD Opteron(tm) Processor 8435

I decided to take the system for a test drive with Olio. Olio is a Web 2.0 toolkit consisting on a web 2.0 event calendar application  which can help stress a system. Depending on your favorite scripting language you can use either PHP, Ruby on Rails, Java as the language used to create the application. (I took the easy way out and selected Olio PHP's prebundled binary kit)

Please don't let the small 2MB kit size fool you thinking it will be a easy workload to test it out. While setting it up I figured that to generate the data population for say 5000 users you will need space with atleast 500GB disk space for the content that it generates for it. Yes I quickly had to figure out how to get a storage array for Olio with about 800GB LUN.

Olio requires a webserver, PHP (of course) and  a database for its metadata store (it has scripts for MySQL already in the kit). The system came preconfigured with Solaris 10 5/09. I downloaded MySQL 5.4.1 beta  and also the Sun WebStack kit which has Apache Httpd 2.2, PHP 5.2 (and also MySQL 5.1 which had not used since I had already downloaded MySQL 5.4 Beta). Memcached 1.2.5 is part of the WebStack download and Olio is configured to use it also by default (but can be disabled too).

Eventually everything was installed and configured in the same X4140 and using the Faban Harness on another system started executing some runs with file store and the meta store preconfigured to handle all the way up to 5000 concurrent users. The results are as follows:


Here are my observation/interpretations:

  • Eventually beyond 10 cores run I find that the system memory (36GB) is not enough to sustain more concurrent users to fully utilize the remaining cores. I would probably need RAM  in the range of 48GB or more to handle more users. (PHP is not completely thread-safe and hence the web server used here spawns processes)
  • This 1RU system can handle more than 3200 users  (with everything on the same system) with CPU cycles to spare is pretty impressive. It means you still have enough CPU to log into the system without seeing degraded performance.
  • Actually you can see here that SMP (or should be called  SMC - Scalable Multi Cores) type system helps when the initial cores are added  instead of using multiple single core systems (ala in Cloud).

 In an upcoming blog entries I will talk more about the individual components used.


why does php has to be thread safe in pre-fork mode ? the default web stack uses apache (pre-fork) along with PHP. here , apache recycles php processes after some requests (unless you explicitly said not to recycle). now, if you still found apache recycling some php processes then
a) either it has crashed (most likley not due to threading issues but other possible issues).

i would be interested in the core dump, if u have one.

Posted by Sriram Natarajan on July 21, 2009 at 07:00 AM EDT #

Hi Sriram,

I guess I am not clear. PHP does not have to be thread-safe in pre-fork mode. But the downside is each concurrent user ends up being a process which eventually sucks up system memory for every users (not an issue but becomes a issue if you have 1000 users spawing processes. Apache provides worker mode also which is threaded/process hybrid which can be used to conserver system memory but does not work in this case since PHP is not thread-safe and hence have to stick with prefork mode.

Hope this helps.

Posted by Jignesh Shah on July 21, 2009 at 07:46 AM EDT #

i agree. in your case, you can reduce the footprint of apache by reducing the number of modules loaded within apache . i hope, u already did that.

- sriram

Posted by Sriram Natarajan on July 21, 2009 at 07:55 AM EDT #

It would be great if you could provide more detailed information on your setup : OS version, how the file store was configured, tunables for the various components used etc.

Posted by Shanti on August 03, 2009 at 07:27 AM EDT #

Hi Sriram,

Yes few of the modules were disabled to reduce the memory footprint.

Hi Shanti,

I forgot to mention that this particular test was done with Solaris 10 5/09 update. The other setup information will take a blog entry so expect a follow on blog entry soon about it. Specially since I am repeating the same setup with WebStack 1.5 /OpenSolaris 2009.06 combination.

Posted by Jignesh Shah on August 06, 2009 at 06:04 AM EDT #

Post a Comment:
Comments are closed for this entry.

Jignesh Shah is Principal Software Engineer in Application Integration Engineering, Oracle Corporation. AIE enables integration of ISV products including Oracle with Unified Storage Systems. You can also follow me on my blog http://jkshah.blogspot.com


« September 2016