rmlocks

gaurav.shetti
Posts: 119
Joined: Fri Feb 27, 2009 9:09 am

rmlocks

Post by gaurav.shetti »

This is the scenario we are facing .
In our vortex scripts we generally name the db // <db= ..>
after we do some of the error processing before due to which some load is borne by testdb. But as this load goes out of control, when many users log in, the entire application fails.

We were thinking of having an automated process which could check the error log files of Vortex and based on the logs, (for eg .. one of the strategy would be checking for certain parameters like could not open locks ... and if many such errors are logged, then depending upon threshold run a shell script which has rmlocks command embedded in it)

Any idea how we can achieve it.
User avatar
mark
Site Admin
Posts: 5513
Joined: Tue Apr 25, 2000 6:56 pm

rmlocks

Post by mark »

Shouldn't need to rmlocks and doing rmlocks -f could be dangerous. Perhaps better to look at the problem in more detail and avoid it. Please provide more detail about what you're doing and what the failure is and what errors you're getting in vortex.log.
gaurav.shetti
Posts: 119
Joined: Fri Feb 27, 2009 9:09 am

rmlocks

Post by gaurav.shetti »

Actually the issue is this
say
we have a script like this

<script language=vortex>
<uses a b c>
<a name=main>
/* Error processing inlcuding string concatenation and algebric additions */
<db= actual path>
.
.
</script>

The question here is ... before setting db to actual path and doing error processing before that would create locks on testdb. Now if the number of users accessing the page is very large, then the locks created would make the inaccessible as data wouldnt be accessed.

If we create a dummy database at the start and then do the error processing, will the locks on testdb be avoided. Or are the locks happening due to some other reason.
User avatar
Kai
Site Admin
Posts: 1270
Joined: Tue Apr 25, 2000 1:27 pm

rmlocks

Post by Kai »

Depending on the nature of the string concatenations and numeric additions, you might be able to avoid a DB open altogether during your error processing.

For example, use <sum> for string concatenation, as it does not cause a DB open like SQL math does:

<sum "%s" "" $string1 $string2>

(The empty string literal ensures string concatenation, not numeric addition.)

Also use <sum> for numeric addition:

<sum "%d" 5 6 $x>

If you can also avoid <fmt>/<strfmt> and limit <if>s to the form <if Value Operator Value>, you should be able to avoid a DB open altogether.
gaurav.shetti
Posts: 119
Joined: Fri Feb 27, 2009 9:09 am

rmlocks

Post by gaurav.shetti »

This would require a lot of change and is virtually impossible now.
Can we set a dummy database at the start of such operations. Can it avoid a db open on testdb thus preventing locks on it?
User avatar
mark
Site Admin
Posts: 5513
Joined: Tue Apr 25, 2000 6:56 pm

rmlocks

Post by mark »

Creating a "dummy" database will just move the problem from testdb to there. It's hard to imagine a little math causing lock problems.

What kind of failure are you getting and what errors are you getting in vortex.log?

If you see a vortex process holding a lock for a long time kill the process and check the vortex.log to see what line it was on when you killed it. Do that a few times to see if it's always the same line.
gaurav.shetti
Posts: 119
Joined: Fri Feb 27, 2009 9:09 am

rmlocks

Post by gaurav.shetti »

Actually we have a couple of scripts which use the module [scconfig].
And the errors we get are these :
000 2009-06-17 01:34:07 [scconfig]:21: Could not open locking mechanism in the function ddopen
000 2009-06-17 01:34:07 [scconfig]:21: Could not connect to /usr/local/morph3/texis/testdb in the function openntexis
000 2009-06-17 01:34:07 [scconfig]:21: Could not open locking mechanism in the function ddopen
000 2009-06-17 01:34:07 [scconfig]:21: Could not connect to /usr/local/morph3/texis/testdb in the function openntexis
000 2009-06-17 01:34:07 [scconfig]:21: Could not open locking mechanism in the function ddopen
000 2009-06-17 01:34:07 [scconfig]:21: Could not connect to /usr/local/morph3/texis/testdb in the function openntexis
000 2009-06-17 01:34:07 [scconfig]:21: Could not open locking mechanism in the function ddopen

hence when many users are using search, we are not sure which script is causing the issue and hence are not able to detect which line is locking the testdb.

Hence 1 option which we considered was to run an automated process to remove locks created on testdb propelled by an automated process. (rmlocks)
User avatar
mark
Site Admin
Posts: 5513
Joined: Tue Apr 25, 2000 6:56 pm

rmlocks

Post by mark »

Possibly the system is so loaded that it's taking too long to get the semaphore. Or too many processes (over 2000) are concurrently connected to the database.
User avatar
mark
Site Admin
Posts: 5513
Joined: Tue Apr 25, 2000 6:56 pm

rmlocks

Post by mark »

You could try using singleuser mode for the early processing as long as it doesn't involve any database. Be sure to turn off singleuser before setting the real db or doing any database ops.
http://www.thunderstone.com/site/texism ... rties.html

<script language=vortex>
<uses a b c>
<a name=main>
<sql "set singleuser=on"></sql>
/* Error processing inlcuding string concatenation and algebric additions */
<sql "set singleuser=off"></sql>
<db= actual path>
.
.
</script>
User avatar
mark
Site Admin
Posts: 5513
Joined: Tue Apr 25, 2000 6:56 pm

rmlocks

Post by mark »

Make that
<sql "set singleuser=1"></sql>
/* Error processing inlcuding string concatenation and algebric additions */
<sql "set singleuser=0"></sql>
Post Reply