Installation ASE on Linux

[charly_q2]

Hi,

currently we are running SAP ASE (non Business Suite) on Solaris but we are planning a test with Linux Systems (SUSE or Red Hat).

Could you provide your experiences with the following topics:

* Is there a best practice guide for ASE on Linux - especially in regards of performance and reliability ?

* file systems as base of an ASE instance ( ext4, xfs, btrfs, zfs )

* RAID constructs for RAW device installations ( md, drbd, zvols )

* limitations on CPU cores or RAM

Thanks

Renate Aufschläger

[hrollizo]

Hi Renate,

ASE Installation Guide for Linux:

https://help.sap.com/viewer/23c3bb4a29be443ea887fa10871a30f8/16.0.3.8/en-US/a6612e5fbc2b10149d8a80b5...

We are using this kind onf FS:

• / ext4
  /boot ext4
  /sybase/ xfs

System Requirements:

• Minimum RAM required for SAP ASE, with default stack size, packet size, and user log cache size – 127 MB
• Minimum RAM per additional user – approximately 324KB
• Default user stack size – 128KB
• Disk Space Requirements
• Linux Disk Space Requirements Product Linux X64 Requirements
• SAP ASE typical installation 921MB
• Default databases created during installation 306MB
• Total 1071MB

2473646 - Performance and Tuning information for ASE - SAP ASE https://launchpad.support.sap.com/#/notes/2473646

1954245 - SYB Performance degradation due to high CPU usage in ASE
https://launchpad.support.sap.com/#/notes/1954245

https://wiki.scn.sap.com/wiki/display/SYBASE/ASE+Performance+and+Tuning

Regards

[sladebe]

My 2 cents.

If you have a lot of Sybase devices based on filesystem files (eg. terabytes), do you have to worry about a boot time filesystem check taking several hours? (only happens after a crash or other unusual condition). My site uses Linux block devices (maybe because of this)

If you have a lot of I/O to the files underlying the ASE devices, all that I/O goes through the Linux virtual memory management system. In Linux, all regular filesystem I/O is actually mapped to pages in virtual memory. In some cases Linux memory management can get weird (system processes start spinning at 100% CPU). In those situations, you need to set the direct I/O option on the Sybase devices. Note, this overlaps with the NUMA discussion below.

Most modern Linux boxes which multiple cores have a non-uniform memory architecture (NUMA). Usually, a socket holds a few cores and some local memory which can be accessed by those cores. CPUs can access memory on another socket, but it's slower. By default, Linux assumes it's a typical multiuser system and tries to move pages onto the socket where each page is used the most. Ie., where the user process is running which accessed neighboring pages recently. But this doesn't apply to database systems where all pages might be accessed by any Sybase process on any core/socket. My site has left NUMA on for ASE applications, but I've read recommendations about turning it off (eg., https://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-thr.... See "Linux's NUMA optimizations don't make sense for typical database workloads"). ASE is not NUMA aware.

If ASE is going to use a lot memory (+400gbytes), it might make sense to have Linux allocate huge pages (2mbytes instead of 4k). ASE will automatically grab the huge pages on boot. This can also help with the virtual memory thrashing problems discussed above. Use "lock shared memory" and "allocate max shared memory"

Use XFS? My understanding is XFS is a journaling filesystem. This being the case, the XFS journaling is redundant with what is essentially journaling in ASE (the transaction logs). So I wouldn't put ASE device files on XFS. But this isn't based on personal experience, just what I've heard.

My site typically has ASE device files on RAID 10 volumes with hardware disk controller.

My site typically turns off hyperthreading for ASE servers

[charly_q2]

Hi Diego,

thanks for sharing your experiences.

Best regards

Renate

[bonusbrevis]

Try these Linux specific docs as well:https://wiki.scn.sap.com/wiki/display/SYBASE/OS+Level+Performance+Tuning

[charly_q2]

Thank you Hector! Only, all these documents seem so "old" to me ...