Live Discover: Query Cancelled: E Process SophosOsqueryExtension.exe exceeded 30% CPU limit

the VM machine has 2 vCPU - sure - when that process runs, it consumes 50% - what the heck is that 30% limitation? Are you serious, live discover will only run longer than 9 seconds on machines with 4 core CPU??

What happens if you change the query to just:

SELECT    
    STRFTIME('%Y-%m-%dT%H:%M:%SZ', DATETIME(file_journal.time,'unixepoch')) AS date_time,
    CASE file_journal.eventType
        WHEN 0 THEN 'Created'
        WHEN 1 THEN 'Renamed'
        WHEN 2 THEN 'Deleted'
        WHEN 3 THEN 'Modified'
        WHEN 4 THEN 'HardLink Created'
        WHEN 5 THEN 'Timestamps Modified'
        WHEN 6 THEN 'Permissions Modified'
        WHEN 7 THEN 'Ownership Modified'
        WHEN 8 THEN 'Accessed'
        WHEN 9 THEN 'Binary File Mapped'
    END AS event_type,
    REPLACE(file_journal.pathname, RTRIM(file_journal.pathname, REPLACE(file_journal.pathname, '\', '')), '') AS file_name,
    file_journal.pathname AS file_path,
    file_journal.sophosPID AS sophos_pid
FROM sophos_file_journal AS file_journal
WHERE
    file_journal.pathname LIKE '$$file_path$$'
    AND file_journal.time > $$start_time$$
    AND file_journal.time < $$end_time$$
ORDER BY file_journal.time DESC

This just uses the same time frame as you define in the variables but only reads from the sophos_file_journal table.

It might be worth running Process Explorer on the client, with the Performance Graph tab of the SophosOsqueryExtension.exe process open.

If that is still slow, then we can look into the data behind this table.

thanks for your answer.

that's the same with your modified query.

It's just, that the query is stopped after 10 seconds due to the 30% for 9 seconds soft limit.

then it stops.

This would only run if I put 2 more CPU core into that machine. And I think that is not a solution.

To prevent users from causing severe performance degradation, the queries have a CPU and RAM limiter that prevents any one query from locking/degrading a system down to unresponsive. 

Are you looking for things on the machines within the last 24 hours?

To prevent users from causing severe performance degradation, the queries have a CPU and RAM limiter that prevents any one query from locking/degrading a system down to unresponsive. 

Are you looking for things on the machines within the last 24 hours?

: "To prevent users from causing severe performance degradation, the queries have a CPU and RAM limiter that prevents any one query from locking/degrading a system down to unresponsive."

A: I think this is a good setting. But from my point of perspective, there must be a way to disable that limitation directly from the query within Central. If you have a critical situation you would not care about performance - you need results, ASAP!

Put a checkbox to Central Query like "Run query with highest priority. This can cause heavy load on the target machine(s)!"

The target machine is a file server. So surely, there are lots of journal files as mentioned by Sophos User930 . Someone modified a special directory and we don't know when. We want to determine what happened afterwards but cannot.

How can I run that query? I just want to start the query at the evening and I don't care for high CPU load on the file server at night.

Update: Support sent me this KB: https://support.sophos.com/support/s/article/KB-000039257?language=en_US

I think it's outdated because I have 9 seconds, written is 12 seconds. And they mention other soft limits as well. I wonder if this product is designed to work on servers where you will find proably more changes than on endpoints. Especially when your servers have been attacked successfully.