04.04.2018 21:16, Peter wrote:
> // With nCPU compute-bound processes running, with SCHED_ULE, any other
> // process that is interactive (which to me means frequently waiting for
> // I/O) gets ABYSMAL performance -- over an order of magnitude worse
> // than it gets with SCHED_4BSD under the sam
Andriy Gapon wrote:
Not everyone has a postgres server and a suitable database.
Could you please devise a test scenario that demonstrates the problem and that
anyone could run?
Alright, simple things first: I can reproduce the effect without
postgres, with regular commands. I run this on my d
Andriy Gapon wrote:
On 04/04/2018 03:52, Peter wrote:
Lets run an I/O-active task, e.g, postgres VACUUM that would
continuousely read from big files (while doing compute as well [1]):
Not everyone has a postgres server and a suitable database.
Could you please devise a test scenario that demon
On 04/04/2018 03:52, Peter wrote:
> Lets run an I/O-active task, e.g, postgres VACUUM that would
> continuousely read from big files (while doing compute as well [1]):
Not everyone has a postgres server and a suitable database.
Could you please devise a test scenario that demonstrates the problem
On 04/04/18 10:34, Peter wrote:
> [...] It does not make sense to me if now we state that
> we cannot do it anymore because single-CPU is uncommon today.
> [...]
+1.-- George
signature.asc
Description: OpenPGP digital signature
Hi Alban!
Alban Hertroys wrote:
Occasionally I noticed that the system would not quickly process the
tasks i need done, but instead prefer other, longrunning tasks. I
figured it must be related to the scheduler, and decided it hates me.
If it hated you, it would behave much worse.
Thats enco
George Mitchell wrote:
On 04/04/18 06:39, Alban Hertroys wrote:
[...]
That said, SCHED_ULE (the default scheduler for quite a while now) was designed
with multi-CPU configurations in mind and there are claims that SCHED_4BSD
works better for single-CPU configurations. You may give that a try,
Stefan Esser wrote:
I'm guessing that the problem is caused by kern.sched.preempt_thresh=0, which
prevents preemption of low priority processes by interactive or I/O bound
processes.
For a quick test try:
# sysctl kern.sched.preempt_thresh=1
Hi Stefan,
thank You, thats an interesting knob!
Hi,
I hope you're doing well.
I was wondering if you had a chance to review my previous email that I sent
to you.
Kindly let me know your interest so that i can get back to you with counts
and pricing available.
Best Regards,
Veronica Baker
From: Veronica Baker [mailto
On 04/04/18 06:39, Alban Hertroys wrote:
> [...]
> That said, SCHED_ULE (the default scheduler for quite a while now) was
> designed with multi-CPU configurations in mind and there are claims that
> SCHED_4BSD works better for single-CPU configurations. You may give that a
> try, if you're not a
Am 04.04.18 um 12:39 schrieb Alban Hertroys:
>
>> On 4 Apr 2018, at 2:52, Peter wrote:
>>
>> Occasionally I noticed that the system would not quickly process the
>> tasks i need done, but instead prefer other, longrunning tasks. I
>> figured it must be related to the scheduler, and decided it hat
> On 4 Apr 2018, at 2:52, Peter wrote:
>
> Occasionally I noticed that the system would not quickly process the
> tasks i need done, but instead prefer other, longrunning tasks. I
> figured it must be related to the scheduler, and decided it hates me.
If it hated you, it would behave much worse
Hi,
On 04.04.2018 12:35, Patrick M. Hausen wrote:
Hi all,
Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin :
I'm just trying to understand these numbers:
file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so
then why is the compressratio only 1.86x ? And why logicalus
Hi all,
> Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin :
> I'm just trying to understand these numbers:
>
> file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so
> then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On
> one hand, 34.2G exactlyf
Hello,
I'm just trying to understand these numbers:
file size is 232G, it's actual size on the lz4-compressed dataset is
18G, so then why is the compressratio only 1.86x ? And why logicalused
is 34.2G ? On one hand, 34.2G exactlyfits to the 1.86x compresstaio, but
still I don't get it. data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213
--- Comment #15 from Mark Knight ---
Created attachment 192199
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192199&action=edit
Kernel config file
Attached kernel config. My kernel is close to generic, extras are:
> options
16 matches
Mail list logo
