[ome-users] Large OMERO Implementation questions

[Wood, Christopher]

Thanks Chris, that is very helpful.

Chris


On 3/3/11 7:57 AM, "Chris Allan" <callan at lifesci.dundee.ac.uk> wrote:

Hi Chris,

Just as an outline...

RAM is not going to scale linearly, particularly with the way the JVM works. You're probably going to hit a hard ceiling between 4 and 6GB for JVM size (there's really not much point in having it larger anyway). With a large database and aggressive PostgreSQL caching your RAM usage could be larger but I would surely doubt a large deployment using more than a few GBs of RAM for this purpose, it's just not cost effective.

Summary: Depending on hardware layout 16, 24 or 32GB of RAM would be ideal for your OMERO server. If you have a separate database server I can't see more than 16GB being of much benefit to you at all.

CPU is really not something that an OMERO system is almost ever limited by. However, when it is limited it's almost always limited by GHz and not by the CPU count. So you're not going to get a huge OMERO experience performance increase by, for example, throwing 24 cores at the problem. Our servers work perfectly well with 8 cores and while you will get some benefit from having more it's not something I would spend a great deal of money investing in.

Summary: Depending on hardware layout 2 x 4, 2 x 6 system core count should be more than enough.

On the disk front really the larger the better and the faster the better, no real surprises there.

On 16 Feb 2011, at 19:42, Wood, Christopher wrote:

>
> Hello Everyone,
>
> We are considering  implementing OMERO as a standard for storing microscopy images at our institute. A typical year would see about 3 TB of image data, and consist of ~300 users in more than 20 different labs. Our I.T. department is concerned about the amount of disk space that will be needed to store and backup all of the data, in addition to providing fast access to the most requested data. We won't have 300 heavy users of the system; more likely (guessing) 50 heavy users with different data sets being imported, exported, and viewed at the same time.
>
> So the questions I have are:
>
>
> 1.  What Hardware specs: How much RAM, number of CPUs, given the number of users and amount of data?

See above.

> 2.  Is any one else using OMERO on this large of a scale? If so, can any tips be provided?

Yes, we are. I think the biggest tip we can give you is to watch performance and watch usage and react accordingly. Each facility's usage patterns are different and will benefit from different hardware setups.

> 3.  Is Linux the best server OS for this? Apache the best web server?

Linux is the best tested and most widely deployed OMERO operating system. I would make your decision based on the staff you have and not what anyone considers "best". The same really applies to Apache, we also make heavy use of Nginx and are very happy with it for what it does.

> 4.  How can we improve the response times for OMERO (tune the performance)?

Bigger, better hardware, smarter indexing of the database based on use and experience. There's really no silver bullet to be honest.

> 5.  Would it be recommended to run the database separate hardware from the OMERO server?

At your scale I would consider it. It's going to give you more flexibility for fitting things into your target performance profile.

> 6.  Are the other ways to separate the processes to improve performance?

The server is threaded, so no. There are multi-process parts of OMERO, including OMERO.tables and the Processor for OMERO.scripts as well as the OMERO.web workers.

> 7.  We currently have a tiered system that keeps the files most often accessed on fast storage, but keeps less accessed items on slower disks.  Will this type of a setup be possible with OMERO, as long as we can mount the data directories to omero server?

I don't see why it wouldn't. OMERO's binary repository structure is quite well established and easy to get your head around. I don't anticipate it being difficult to map to whatever tiered storage system or tools you have in mind.

>
> Thanks in advance.
>
> Chris

-Chris