You can get good performance on any platform.  The real keys to performance are how you specify and configure the hardware and software for the kind of workload you will run.  I share Robert Cemper's preference for Linux or UNIX, but a good Windows administrator can make a Windows server run very well.

Have you been in contact with your InterSystems account team?  They can be a good source of information in the context of what your application needs are.

Erik

Eric, your best bet is to investigate at operating-system level; a dead job means it's no longer around as far as can be detected within Ensemble.  As to what to check, this depends very much on the specific OS platform you're running; different ones have different tools.

For Linux, try looking in /var/log/messages.  For Windows, the Event Viewer is where to go.  And there may be useful information in the Caché cconsole.log.  

The WRC can help you with getting to the bottom of problems like these because there are many reasons why a job might die unexpectedly.

Erik

Ken, 

Are you using Docker for Windows?  I don't recommend it if you have access to a Linux system or Linux VM.  There are many frustrating limitations with it.

You can try to start your container without the --detach flag to see more about what is happening at container startup.  If everything seems right, but you still have a problem, try reaching out to the WRC for help.

Erik

Robert, although we only support containers on Linux, we have some information concerning Docker for Windows since many people find themselves in just this situation.

https://community.intersystems.com/post/using-intersystems-iris-containers-docker-windows
 

For your Durable %SYS directory, try a named volume instead of a bind mount (use docker volume create ...).  

Thanks for your post and for all your contributions in the DC.   Erik

There are many tools available for backup-and-restore.  InterSystems publishes some helpful information in the Caché Data Integrity Guide (https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_backup).  

If you are a supported customer, your sales engineer can be a good resource, and the WRC is always available to help you solve problems.

Erik

Sylvie, you didn't specify the exact version you are using; in v2016.1.1 and later, the limit of 999 journal files per day was removed.

If you are creating a lot of journal activity, and the 999 limit applies to you, you can also increase the size of each journal file so fewer are created each day.  As Eduard posted, testing your workload is the way to determine the journal space you need.

Farhan,

It's certainly possible to create a user-defined audit event and add audit events from your application code.  What's the purpose of tracking patient IDs?

Audit events are stored in the CACHEAUDIT database and by default are purged after a set number of days. So using the audit log to track patient IDs might not be the right solution.  It all depends on what your ultimate goal for tracking is.  

You might want to contact the WRC or your account team for more-specific help.

Erik

Robert's suggestion is the answer nearly all the time, but it's interesting that the messages seem to show an SSH server responding on the port you are using. If you want to use SSH, Robert is right: use an external SSH client and open port 22 on the remote server.

If you definitely need to use Telnet, you need to have a Telnet server (something like telnetd) running on the remote Ubuntu server and open TCP port 23.

If you are stuck, contact the WRC (support@intersystems.com) and an advisor can help you.

Erik

HP-UX uses initscripts to start processes. So you need an initscript which includes commands to start, stop, and check status of processes.

Let's take the Arbiter; it's a standalone process at OS level and is easier:

The Arbiter is an instance of ISCAgent, whose initscript is likely at /sbin/init.d/ISCAgent on your HP-UX system.

Symlink to that script in the runlevel directory for the runlevels you need this to run; this should be /sbin/rc3.d for runlevel 3 or /sbin/rc4.d for runlevel 4. You can review the HP-UX runlevels by reading the manpage for init (1M) (the command man init should get you there).

In those directories, you'll see names starting with S##name and K##name (digits for the #). This signals which services are (S)tarted or (K)illed when the system switches to this runlevel. On my test machine here, in /sbin/rc3.d I see S900ISCAgent, and I can see that it would start after

S870hpsmhd.

You would need a similar initscript which would start Cache'. I would expect that the Arbiter would be run on a host distinct from its mirror members. You can review the ISCAgent initscript to get a sense of how these are organized.