Closing as this is not any issue anymore since the switch to PostgreSQL.
Mathieu
Hey Maxim,
> Perhaps we should run 'vacuum' when invoking 'guix gc' or at some other
> key places (where lots of data gets removed from the DB). There's also
> the auto_vacuum PRAGMA, which is not enabled currently:
Vacuuming periodically seems important, however, it didn't resulted in
Hello,
Mathieu Othacehe writes:
> Hello Chris,
>
>> I think Ricardo mentioned that the machine running Cuirass uses an SSD
>> for the root filesystem, so moving the database there may help?
>
> Looks like the database was already on the SSD before my tmpfs
> experiment.
>
> mathieu@berlin ~$ df
> I don't really get why I/O pressure on /dev/sdb could impact /dev/sda.
Turns out /tmp is mounted on /dev/sda, so all the building and ISO
production are first written on /dev/sda before being copied to the
store in /dev/sdb.
Reducing the build activity of berlin, as Ludo proposed should help
Hello Chris,
> I think Ricardo mentioned that the machine running Cuirass uses an SSD
> for the root filesystem, so moving the database there may help?
Looks like the database was already on the SSD before my tmpfs
experiment.
--8<---cut here---start->8---
Ludovic Courtès writes:
> Hi,
>
> Mathieu Othacehe skribis:
>
>>> I have now copied the database to a tmpfs mounted directory to make sure
>>> that those inconsistent duration are only caused by the I/O pressure on
>>> berlin.
>>
>> This helps a lot. The Cuirass web service has been running
Hi,
Mathieu Othacehe skribis:
>> I have now copied the database to a tmpfs mounted directory to make sure
>> that those inconsistent duration are only caused by the I/O pressure on
>> berlin.
>
> This helps a lot. The Cuirass web service has been running smooth since
> two days, without any
Hello,
> I have now copied the database to a tmpfs mounted directory to make sure
> that those inconsistent duration are only caused by the I/O pressure on
> berlin.
This helps a lot. The Cuirass web service has been running smooth since
two days, without any inconsistent query times.
I'm
Hello,
> this should improve the situation, even if I still observe some
> inconsistent execution duration.
I tried to use the two following pragma:
--8<---cut here---start->8---
PRAGMA synchronous = OFF
PRAGMA mmap_size = 10737418240
--8<---cut
Hello,
I pushed and deployed several patches that:
- update metrics in a single transaction
- register builds in a single transaction
- use a single write database worker, queuing queries and submitting
them by batches (in a single transaction).
- optimize some SQLite parameters (decrease WAL
Hello,
Over the last few weeks I made sure that all Cuirass SQL queries were
using indexes. As the "Builds" and "Outputs" tables can be really large,
having queries covered by indexes is imperative for consistent queries
duration.
However, I observed that some queries have inconsistent
11 matches
Mail list logo
