Showing posts with label command-line. Show all posts
Showing posts with label command-line. Show all posts

Friday, March 11, 2011

Shared Memory and Semaphore Limits in Red Hat ES

I ran into a few issues recently, where I ran out of semaphore arrays when implementing a new web application. The application is a single-tier setup with all 34 databases on the same server which can get pretty busy at times and needs to have the kernel tweaked a little bit to allow for a large amount of concurrent processes.

To check the shared memory and semaphore limits in RHEL:

ipcs -al

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 256 *** <- What I needed to update
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

------ Messages: Limits --------
max queues system wide = 32
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

Apparently the maximum number of arrays was too low (default on RHEL was 128 I believe).

To change THIS specific value, we need to update the running kernel parameters like so:

echo "250 32000 32 256" > /proc/sys/kernel/sem

**Note this will NOT MAKE THE KERNEL CHANGES PERMANENT

Obviously the format is:

[per array] [system wide] [per semop] [max arrays]

To make the changes permanent, we need to update /etc/sysctl.conf with the following:

kernel.sem = 250 32000 32 256

Another good change would be to update the max queues at the same time:

kernel.msgmni = 128

We could run 'sysctl -p' to update the running kernel with the permanent settings.

Double check with 'sysctl -a'!

Tuesday, July 28, 2009

Various Linux Commands - When you Need 'em!

From time to time I'll run into a request like "OMG, you HAVE to fix the mail queue RIGHT NOW!! We can't get our report and it's stopping us from submitting our POs in time for tomorrow's delivery!". Being the good (and prepared) Sysadmin that I am, I'm always ready to jump in and help out...My problem is that I don't always write down important commands where I should! (They're scattered all over the place, mostly in the form of post-it notes with poor handwriting and coffee stains)

Yes yes, I know it shouldn't take me 5 mins to search google to figure out how to re-run a sendmail queue, but these things slip your mind sometimes...especially when you have 6 people, including a manager and a director, looking over your shoulder waiting for the mail to 'start flowing'!

This is just a quick and dirty list of the commands that are specific to the things I deal with on a day-to-day basis. I won't go into much detail, so if you'd like more information: stop being so lazy and google it yourself!

Sendmail

'mailq' - List locally-queued mail
'mailq -Ac' - List sent, but undelivered, mail
'/usr/sbin/sendmail -v -q -d3.30' - Show current load in relation to sendmail.cf settings
'/usr/sbin/sendmail -qR /path/to/queue' - Force a mail queue run immediately
'tail /var/log/maillog' - Show output of mail log

Samba

'smbpasswd -a ' - Add user to samba
'smbpasswd -d/-e ' - Disable/enable samba user
'smbpasswd -n ' - Null password for user

Printing

'lpstat -t' - Show every printer, including queue
'/usr/bin/enable or disable' - Enable or disable printer, use the ABSOLUTE path
'lp -i -H restart' - Restart print job
'lpmove ' - Move a stalled job to different printer
'lprm -P ' - Remove print job
'lpadmin -P -E -v socket://ip.addr.of.prtr:9100' - Add and enable a new printer

Generic

'netstat -an' - Show all listening ports
'lsof -Pnl +M -i4' - Show files/daemons listening on specific ports/protocols
'w | wc' - List # of currently logged-on users
'finger ' - Not what you think...it's a legit command...I swear!
'chage -l ' - Show password aging for a user

I'll be updating this post with things that I think may be helpful to others...Personally, I didn't even know about the sendmail command for showing the settings vs. the current load...I found it on a sendmail development project blog from about 8 years ago...you never know!