Topics

Huge numbers of Page Faults on YaDD compared to YaND

Dirk Claessens
 

Hi Mats,

Below is a screenshot of my Win 10/8GB (Dutch) system. The 3d column "Harde fouten/sec" = Hard page errors/sec is showing zero for all apps/services, and it stays there.
On your system, all apps are showing page faults but Yand/Yadd/SDRConsole show the most.
I have no idea why...

Perhaps, as a first test: reboot the system, then run only one instance of Yadd or Yand, and see what happens.
If the page fault count goes down dramatically, start another instance, see what happens, and so on.
This is the best I can think of, this is hard to diagnose from a distance.

Regards - Dirk



On 7/05/2019 21:48, Mats A wrote:
Hi Dirk,

On Tue, May 7, 2019 at 08:38 PM, Dirk Claessens wrote:
are Yadd/Yand the only applications that show this behaviour?
Yepp, look at the screenshot below.


The page file is 8 GB, but i doubt the memory are low. Please look at the screenshot in my previous post, it is steady on 2.5 GB.
There may be some correlation with the page faults and the size of the databases as the 2187.5 database contains about 107.000 records and the 2182.0 database contains 478 records. If that is the case i still don't understand why the page fault delta count up exactly the same amount for every second even if no message are decoded or the databases are not written to or read from (unless there are some routines that read from the database every second).

The behavior described on the "new" computer are the same as with the "old" PC, that only had 4 GB of memory from the beginning, which later on was expended to 8GB wihtout any noticeable difference.

It's not a big deal but It caught my attention when running YaND, which i believe share much of codebase with YaDD.

Best regards
//Mats

Mats A
 

Hi Dirk,

On Tue, May 7, 2019 at 08:38 PM, Dirk Claessens wrote:
are Yadd/Yand the only applications that show this behaviour?
Yepp, look at the screenshot below.


The page file is 8 GB, but i doubt the memory are low. Please look at the screenshot in my previous post, it is steady on 2.5 GB.
There may be some correlation with the page faults and the size of the databases as the 2187.5 database contains about 107.000 records and the 2182.0 database contains 478 records. If that is the case i still don't understand why the page fault delta count up exactly the same amount for every second even if no message are decoded or the databases are not written to or read from (unless there are some routines that read from the database every second).

The behavior described on the "new" computer are the same as with the "old" PC, that only had 4 GB of memory from the beginning, which later on was expended to 8GB wihtout any noticeable difference.

It's not a big deal but It caught my attention when running YaND, which i believe share much of codebase with YaDD.

Best regards
//Mats

Dirk Claessens
 

Hello Mats,

If Windows runs low on physically available memory, it will start using virtual memory from its page file. (pagefile.sys in the root directory)
Memory blocks will be swapped (exchanged) in/out from/to this file and memory as needed. This will cause disk activity of course.
So a page fault is not a true error, but an indicator.

What I'm wondering about: are Yadd/Yand the only applications that show this behaviour?
What you could check is Windows' page file setting. Recommended size is 1.5 x RAM size, so about 12GB for your system.

Cheers - Dirk

On 7/05/2019 15:16, Mats A wrote:
Hi all,

I got my hands on a cheap refurbished small server which has replaced the trusty I3 which has been humming along 24/7 since 2015.

Maybe this is a silly question which has been discussed before, or is off topic for this forum, so please bare with me.
But why are there such a difference in the Page Faults and PF Delta between YaDD and YaND?



All instances listed above was started at the same time, and has been running happily 24/7 since Saturday.
All YaDD and YaND instances seems to increase by the numbers given in the PD Delta column each second, which accumulates quite a bit over time for the YADD instances as the PF Delta for these are about ~500. On the other hand YaND (and the rest of the instances in Task Manager) seems to be quite steady around 0.

Do this have any significant impact on the load of the processor, which in my case adds up by YaDD x 8 @ ~2-4% to ~20%, whereas YaND seems to be humming along around 1%?
Are there anything I can do about it?

The PC is a refurbished Fujitsu small office server (which is very silent) with a 4 core XEON E3 processor @ 3.3 GHz and 8 GB RAM and the OS is Win 7.
SDR console V3 takes ~20-23% of the processor load @ 3MHz BW and ~25-28% at 6 MHz BW, which is quite impressive.
The memory used seems to be quite modest and steady.



Best regards
//Mats

Mats A
 

Hi all,

I got my hands on a cheap refurbished small server which has replaced the trusty I3 which has been humming along 24/7 since 2015.

Maybe this is a silly question which has been discussed before, or is off topic for this forum, so please bare with me.
But why are there such a difference in the Page Faults and PF Delta between YaDD and YaND?



All instances listed above was started at the same time, and has been running happily 24/7 since Saturday.
All YaDD and YaND instances seems to increase by the numbers given in the PD Delta column each second, which accumulates quite a bit over time for the YADD instances as the PF Delta for these are about ~500. On the other hand YaND (and the rest of the instances in Task Manager) seems to be quite steady around 0.

Do this have any significant impact on the load of the processor, which in my case adds up by YaDD x 8 @ ~2-4% to ~20%, whereas YaND seems to be humming along around 1%?
Are there anything I can do about it?

The PC is a refurbished Fujitsu small office server (which is very silent) with a 4 core XEON E3 processor @ 3.3 GHz and 8 GB RAM and the OS is Win 7.
SDR console V3 takes ~20-23% of the processor load @ 3MHz BW and ~25-28% at 6 MHz BW, which is quite impressive.
The memory used seems to be quite modest and steady.



Best regards
//Mats