SQL-Ledger Homepage

SQL-Ledger User Forum

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order
gripa(R)

Homepage E-mail

Spain,
22.06.2015, 11:38
 

Delay in database (General)

Beginning of this year we had delays in the postgres database, so that mutations where seen only after (many) hours.

Thanks to Dieter we have got a new Form.pl file and everything worked great untill now, because we have the same problem again.

We increased the internal memory of the dedicated server from 4 GB to 16 GB, but the problem remains.

Doe anybody know what this is ? (working with 2.8.30 and we are unable to upgrade the databases tot newer versions).

---
Kind Regards,

Martin Boulonois
Accountnet

clusters(R)

25.06.2015, 19:31

@ gripa

Delay in database

More info. needed. How you know for sure it is the database? If fixing Form.pl had solved your problem it is pointing to Perl perhaps?

16G is a boat load and did you configure Postgres to utilize all these memories?

I run both the 2.8 and 3 on an older and a newer Linux system and u must have a very high demand system...

Also, what you mean by mutations? I am not too sure if upgrading your database would solve your issues. I also bet you are running your system on an older kernel?

Beginning of this year we had delays in the postgres database, so that
mutations where seen only after (many) hours.

Thanks to Dieter we have got a new Form.pl file and everything worked great
untill now, because we have the same problem again.

We increased the internal memory of the dedicated server from 4 GB to 16
GB, but the problem remains.

Doe anybody know what this is ? (working with 2.8.30 and we are unable to
upgrade the databases tot newer versions).

gripa(R)

Homepage E-mail

Spain,
26.06.2015, 02:20

@ clusters

Delay in database

Thank you for your reply.
As we are accountants and not IT specialist, we don't know for sure that it is a problem with the database.
The problem is that the one who installed a few years back these databases, was putting them on an other place as normal with his own security way of handling these databases, so that we are unable to dump these databases to try them on an other SQL ledger system.

I have to ask the the company who is hosting and manageing the dedicated server (TMD) if they cinfigured Postgres to utilize this memory.

What I mean with mutations is a booking in the system (posting).

We use the latest kernel

Hope to hear from you.

---
Kind Regards,

Martin Boulonois
Accountnet

clusters(R)

26.06.2015, 12:34

@ gripa

Delay in database

As we are accountants and not IT specialist, we don't know for sure that it
is a problem with the database.

Understood, so I don't believer there were error logs then?

The problem is that the one who installed a few years back these databases,
was putting them on an other place as normal with his own security way of
handling these databases, so that we are unable to dump these databases to
try them on an other SQL ledger system.

It sounds like the physical and logical layers should not matter to you if you would just wanted to dump a database out for testing. My guess is that you run separate dbs for each clients, so you have many. You may have a hard time dumping out the db using Postgres export function if you are not an IT guy. Now, can you just use SL's system->backup->save to file to dump the data?


I have to ask the the company who is hosting and manageing the dedicated
server (TMD) if they cinfigured Postgres to utilize this memory.

What I mean with mutations is a booking in the system (posting).

It's probably Perl/coding related issues. I would first learn how to make that error repeatable. That would help you to troubleshoot. Does it happen to only one user? As 2.8 should run very stable after all these years, a good chance would be the kernel/packages upgrade and the 2.8 isn't liking something in the new Perl or new Postgres...I had that happened before with Perl...so please go ask you hosting company about recent upgrades and try to match when this mutation begin to occur...

Double posting is no good...Tim

Back to the board
Thread view  Mix view  Order
976 Postings in 320 Threads, 326 registered users, 56 users online (0 registered, 56 guests)
SQL-Ledger User Forum | Admin contact
RSS-Feed
powered by my little forum