something like this works for me

echo "h" | iris session [instance] -U [namespace] [routine]

Are you looking in ^JOBEXAM or the SMP?

As a out of the box idea I am going to suggest screen so you can just keep your session running.

I know with VPN connections keeping a session going can be difficult.

If you use PURGE^JOURNAL it will keep you from doing anything that will break your system.

I would catch up your DR async before deleting journals.

You should look at this Purging Mirror Journal Files

Yes you could edit the database properties ^DATABASE so a particular database did not journal but I would be worried that the journals will also change the other datasets so I would unmount them before applying journals.

It might be better to create a parallel instance and mount the restored database and then replay the journals.

For a production issue I would reach out to the WRC.

Two possible issues:

Are you running a backup?

Do you have a network mounted filesystem like NFS or SMB?

We need to see messages.log or cconsole.log for the time it was happening.

One thing you can do is run it in steps for both the compaction and the free so you have performance effect data on your actual system. Do a run to compact and free of maybe 1 or 10 Gb.

Be ready for the WIJ to expand.

Try it on a non production copy if you can first and run an Integchk on the dataset after.

Make sure you are on a current version of Cache or IRIS since some versions had issues.

Know when your system really has it low utilization period. You might have midnight/end of day processing or someone might do the weekly ETL on the weekend.

I no longer have a shadow to test with but something like:
echo  "d tag^routine \n h" | csession [instance] -U %SYS
You need Unix passthough authentication to work.
Managing and Monitoring Shadowing might help you find the data you want

The affected class is not part of the required install for Cache 2018.1.5.659.0 or IRIS 2020.1.1.408.0.

I would search filesystems for JndiLookup and log4j.

The ^DATABASE routine in %SYS allows you to edit the size. Sizing a CACHE.DAT avoids the on the fly expansion that would otherwise happen. Some people thought this would be a performance benefit.

Looks like you can set charset to UTF-8 using the docs here. You might need the full version to do that.

What charset do you want to use? That may be the issue.

I use putty too.

Intersystems has worked hard but encryption is not free. Do you have something like batch processing? You would notice an impact more there then on a 1 second query. I would worry more about key security and recovery. Encryption also has a serious impact on the ability of modern SAN storage to dedup and compress which could result in higher than expected storage costs.

You might look at this tool combination for the last journal file.

Convert Journal Files Using ^JCONVERT and ^%JREAD

If you have not already, migrate to solid state disks.

It is weird that the page Vic recommends does not mention that.

Check Startup namespace for the user in ^SECURITY maybe.

Here is a link to the Cache document - https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal#GCDI_journal_view