Thunderstone Support Forums

We recently did a install on linux and get a lot of message like this:

Open shared mem failed, No space left on device

We run more than 100 concurrent crawling process,

I have semaphore values as follow for the system

/proc/sys/kernel/sem
1250 32000 200 512


What is the cause/solution available?

Thanks.

Shared mem is a different resource than semaphores. Under Linux, a single shared memory segment is needed by Webinator for each active database (eg. active profiles X 2) on the system, plus one for the Texis Monitor.

Sometimes shared mem segments are not deleted when a database is inactive, causing them to accumulate and possibly cause the message you saw. You can check how many segments are on the system with ipcs. Except for the segment with key 0xdbaccee5, you can safely delete other shared mem segments created by Texis (with ipcrm), once walks are stopped: if they are still needed, they will be re-created automatically.

Before deleting a segment, be sure it was not created by other software, such as Apache. Such software may also be the cause of running out of segments. Check your Linux manuals for how to increase the number of available shared mem segments on the system.

Thanks Kai,

I was too obsesses with semaphore and I only have 128 for shmseg.

Just change to 4096 and seems a lot better now.

Will keep watching.

BTW, in case anyone wonders,

On linux, do the change to
shmmni -- max number of identifier?

It is the same as shmseg on other ssytem.

Also changed in /etc/sysctl.conf add:

kernel.shmmni = 4096

Thank a lot.

WT

I'm also getting this error after creating/deleting several temporary databases. Should I delete the shared mem segment after I delete a database? How would I know what the key is to delete?

Use rmlocks -f to remove the shared mem before removing the db.

I'm getting the same error when trying this:

100 Open shared mem failed, No space left on device, trying again

If you run ipcs -ma (or similar options) you should see the shared memory segments owned by the Texis user that have NATTCH 0, and all the same size, indicating that no process is currently attached to them.

I know you can use ipcrm -m to remove a shared memory segment. Would you happen to know a grep command that would be able to identify and remove those shared memory segments?

Here's one I commonly use:

ipcs -m | awk '/^0x/ && $6 == 0 && $1 != "0xdbaccee5" {print $2}' | while read id; do ipcrm -m $id; done

It assumes ipcs -m output has the key in hex at start of line, followed by shmid, and nattach as the 6th column, e.g.:

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0011b2fb 1514307584 build 666 125668 0
...

The `!= "0xdbaccee5"' is to avoid removing the main Texis Monitor mem segment (which is not a lock structure). `$6 == 0' ensures only unattached segments are removed.

Thanks Kai! This is very helpful.