|Newbie questions about Pliant
my database is getting large, and "db store" takes a long time
|Message posted by borisr_eitman on 2007/02/04 00:30:28
|My database has reached 9000 * C records where C is some constant < 10.
It takes now about 5 seconds to perform a "db store", which is an unsuable
delay for a GUI. Because my pliant server crashes some time,
I have to make sure that all important info is synchronized on disk.
Right now I have a store operation performed when a customer finalizes an order. It would be ideal if I could
run a db store operation in a thread upon order completetion. So the control
to the user will be returned before db store is completed. How would I do this
in .page environment without breaking anything ?
|Message posted by maybe Hubert Tonneau on 2007/02/04 01:06:06
|You don't have to use the 'store' method.
Your datas will be safe anyway because each time your application modifies some
datas, the modifications instructions are appended on disk file immediately.
|Message posted by borisr_eitman on 2007/02/04 03:20:39
|What does "db store" do that is not done automatically ?
What you describe is not my experience. I run version 96. When I have stopped the
server with Ctrl-C, I lost orders that weren't saved with "db store". Perhaps there's a
difference between creating new records and modifying existing ones ?
|Message posted by maybe Hubert Tonneau on 2007/02/04 11:51:12
|There are two scenario:
either your database has no log so is stored in a single .pdb file,
or it has a log so is stored in a .pdf plus a .log file.
When you modify some datas,
if there is no log file, the modification instructions are append immediately
to the .pdb file
if there is a log file, the modification instructions are append immediately
to the .log file and the 'precovery' tag is added to the .pdb file specifying
the offset to read the .log file from for proper recovery
Now, when you call 'store' method, which is automatically called once every
24 hours at low traffic time (Pliant does statistics to automatically discover
lowest traffic time), a new fresh .pdb is written so that it gets minimal again.
Just imagine that you have a .pdb and a .log file, and that in your application,
you modify the same field 1000 times. Then the instruction to modify the field
will be stored 1000 times in the .log file, so that loading the database will
be slow. Through writing a fresh .pdb we get back to the situation where it's
written only once so that loading is more efficient.
But is we don't do that, no data will be lost: only the restarting of the server
will be slower.
If you experimented a data loss, please try to reproduce it. Data loss is
always possible, but the way Pliant database works makes it really hard to
trigger. Anyway, please notice that Pliant database relies on the underlying
kernel to keep datas safe: I mean, when some modifications append, the
modifications instructions are immediately written to the .log or .pdb file,
but the operating system is not instructed to flush the cache immediately,
so in case of an operating system failure, loosing the last modifications
would not be surprising. On the other hand, when a fresh .pdb file is
written through 'store' method call, then the flush instruction is sent
immediately to the operating system is order to try as hard as possible to
avoid loosing old datas.
In very fiew words, Pliant database assumes reliable underlying, so it's
really stable if you run it on a well selected Linux kernel with well
selected hardware (drivers), with an UPS and software RAID1 disks.
Early versions of Pliant databases had a bug that would lead to some datas
loss from time to time, but as far as I remember, it has been corrected for
two or three years, so I have not experimented any data loss on production
machines for years.
What I suggest is you to check yourself that that anytime you modify some
datas in your database, you truely find the changes at the end of the .log
if you have one, or at the end of the .pdb
|Message posted by maybe Hubert Tonneau on 2007/02/04 11:55:53
|Are you running Linux or Windows ?
If you are running Linux, there might have access rights problem to the files,
and if you are running Windows, there might have filesystem interface bug in
Pliant making it work differently than under Linux.
|Message posted by borisr_eitman on 2007/02/04 23:12:58
|I am running linux. The directory that contained the .pdb files had the wrong permissions,
and didn't allow creation of new files. Maybe that is why I don't have .log files.
Do I need to do anything specific to enable db log files ?
Do you recommend enabling the db log files ?
Btw, I having again the problem crashing without error. The last time I had it, I realized
that my server was running some old-code sites that had some style definitions that were
clashing with my new sites. I don't understand why that happened, but in anycase, I disabled those old sites,
and the problem went away when I wasn't using execute_dynamic_page. Now it is back again,
I am trying to track it down.
|Message posted by maybe Hubert Tonneau on 2007/02/05 10:31:48
|Pliant must have read and write access to all of it's /pliant_security/
and /pliant_data/ trees.
If you don't want Pliant to build an infinit log for your database,
just remove the 'log' option in the 'load' method.
Also, unless you have disk space constrains, keeping an infinit log is
very valuable because it might enable you to selectivery move some parts
of your database back, as an exemple if you discover that an account has
been stolen and used to perform changes or just have a user telling you
he did delete some important datas by mistake.
|Message posted by maybe Boris Reitman on 2007/02/08 02:16:28
|So, at what point can I delete the log ? The "store" operation doesn't clear it.
|Message posted by maybe Hubert Tonneau on 2007/02/08 11:22:04
|From the logical point of view: never.
If you select a log, it's because you want to keep it forever.
If you don't want a log, just dont ask for some when you load the database.
even if it makes no sence, you can delete the log just after calling the