On 16/10/14 16:02, Christopher Samuel wrote:
> No worries, we're going to test out ours in a sandbox as well, so we'll
> be able to compare it to our (pretty beefy) DB servers.
It took around 2 minutes to add all the indexes in our sandbox, thats
with a total of about 6 million jobs across 5 sys
On 16/10/14 00:40, Ulf Markwardt wrote:
> we have tested this migration in a VM sandbox. After >30 min we decided
> to interrupt the procedure and look for a faster solution.
No worries, we're going to test out ours in a sandbox as well, so we'll
be able to compare it to our (pretty beefy) DB se
Hi Chris,
Could you define too long, and what problems it caused please?
we have tested this migration in a VM sandbox. After >30 min we decided
to interrupt the procedure and look for a faster solution.
The "foreign constraints" came from another database a colleague of mine
has installed,
Hiya Ulf,
On 10/10/14 20:05, Ulf Markwardt wrote:
> the update procedure 2.6->14.11 of the slurmdbd adds a couple of
> indexes to the database. For >> 10 Mio job entries this takes too
> long.
Could you define too long, and what problems it caused please?
We're looking at upgrading Slurm to fr
Please see the slurmdbd.conf man page:
http://slurm.schedmd.com/slurmdbd.conf.html
There are five separate configurable purge values (for jobs, steps,
reservations, events, and suspend records). None are purged by
default. Setting appropriate purge values is strongly recommended and
may re
Update: A sandbox test leads to these problems:
mysql> delete from taurus_job_table where time_endhttp://www.tu-dresden.de/zih
smime.p7s
Description: S/MIME Cryptographic Signature
delete from `taurus_job_table` where time_end>unix_timestamp('2013-08-01')
I know... better like "where time_endhttp://www.tu-dresden.de/zih
smime.p7s
Description: S/MIME Cryptographic Signature
