Hi,
I kept the full answer in history to keep the list informed of your full
answer.
My answer down below.
On Mon, 11 Oct 2021 11:33:12 +0200
damiano giuliani wrote:
> ehy guys sorry for being late, was busy during the WE
>
> here i im:
>
>
> > Did you see the swap activity (in/out, not
On Sat, 9 Oct 2021 09:55:28 +0300
Andrei Borzenkov wrote:
> On 08.10.2021 16:00, damiano giuliani wrote:
> > ...
> > the servers are all resoruce overkills with 80 cpus and 256 gb ram even if
> > the db ingest milions records x day, the network si bonded 10gbs, ssd disks.
I don't remember if we
Ah... That's the first thing I change.In SLES, that is defaulted to 10s and so
far I have never seen an environment that is stable enough for the default 1s
timeout.
Best Regards,Strahil Nikolov
On Sat, Oct 9, 2021 at 9:59, Jehan-Guillaume de Rorthais
wrote:
Le 9 octobre 2021 00:11:27
Le 9 octobre 2021 00:11:27 GMT+02:00, Strahil Nikolov a
écrit :
>What do you mean by 1s default timeout ?
I suppose Damiano is talking about the corosync totem token timeout.
___
Manage your subscription:
What do you mean by 1s default timeout ?
Best Regards,Strahil Nikolov
On Fri, Oct 8, 2021 at 16:02, damiano giuliani
wrote: ___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home:
On Fri, 8 Oct 2021 15:00:30 +0200
damiano giuliani wrote:
> Hi Guys,
Hi,
Good to hear from you, thank for the follow up!
My answer below.
> ...
> So it turn out that a lil bit of swap was used and i suspect corosync
> process were swapped to disks creating lag where 1s default corosync
>
Hi Guys, after months of suddens unexpected failovers, checking every
corners and types of logs without any luck, cuz no logs and no reasons or
problems were shown anywhere, i was on the edge of madness i finally
managed to find out what was the problems of this suddends switches.
Was a tough
On Fri, 23 Jul 2021 12:52:00 +0200
damiano giuliani wrote:
> the time query isnt the problem, is known that took its time. the network
> is 10gbs bonding, quite impossible to sature with queries :=).
Everything is possible, it's just harder :)
[...]
> checking again the logs what for me is not
hi guys thanks for supporting.
the time query isnt the problem, is known that took its time. the network
is 10gbs bonding, quite impossible to sature with queries :=).
the servers are totally overkilled, at database full working loads 20% of
the resources have been used.
checking again the logs
Hi,
On Wed, 14 Jul 2021 07:58:14 +0200
"Ulrich Windl" wrote:
[...]
> Could it be that a command saturated the network?
> Jul 13 00:39:28 ltaoperdbs02 postgres[172262]: [20-1] 2021-07-13 00:39:28.936
> UTC [172262] LOG: duration: 660.329 ms execute : SELECT
> xmf.file_id, f.size, fp.full_path
>>> damiano giuliani schrieb am 13.07.2021 um
>>> 13:42
in Nachricht
:
> Hi guys,
> im back with some PAF postgres cluster problems.
> tonight the cluster fenced the master node and promote the PAF resource to
> a new node.
> everything went fine, unless i really dont know why.
> so this morning
11 matches
Mail list logo
