Jet Temp File Issue

​

Something to check. It won't help your problem, but it might give a more accurate file count:

- I believe that Orion monitor has an attribute/config of 'INCLUDE SUBDIRECTORIES" set to "yes" by default so the file count may be all files in C:\Windows\temp.  I've overridden mine to "no"

- The "file extension filter" in that monitor is set to "jet*.tmp" but it appears to count all files in C:\Windows\temp?

FYI: I also have thousands of *.tmp files in this folder, that started occurring after I upgraded Orion to the latest version (a few months ago).  This behavior was not occurring before the upgrade.  I saw your previous post JET File monitor for Orion Services Question and I guess the SNMP/Syslog service are doing it, but I can't shut these off. Hopefully they will fix this soon

Also: A long time ago (on Orion v11) I had an issue with *.jet files building up on my Orion server, and Orion would eventually grind to a halt, services bouncing repeatedly, etc.. I found some procedures that, collectively, seemed to work...for awhile.  *I believe* the main issue what that when Orion was shut down (like from the services UI and all the services show "stopped") there were actually many Orion collector processes still running, and they would take *minutes* to finally shut down on their own.   I believe when I rebooted the server without waiting for them to shut down or the server was booted (automatically, for OS patching), those processes were causing some issues as they did not shut down properly.   When I moved my Orion app server to a new Windows server the services and processes shut down in seconds and I haven't had these issues with my Orion server since.

If it helps, and you're desperate these are some of the posts in my docs I used to try to repair things when I had "general Orion instability issues". Often I would have many *.jet.tmp files in C:\Windows\temp, but not always. It didn't stop it my issues from recurring, it just seemed to "clean it up" for awhile until something significant occurred (like a boot for OS patching, or Orion had issues opening new ports).  These are "old" so I'd exercise caution on performing any of these steps on a newer Orion install.  For the last one, I think Orion doesn't even use MSMQ in v12 unless it has an issue with RabbitMQ.   I think when I spoke to support about my issues they basically said they were likely related to other things, but no one could find a cause.  I suspect that the issues came from either custom SAM monitoring (like executing scripts) as hey, it's custom and likely not well tested, or from running several of the AppInsight SAM montors (we had issues with them and I've since removed all of them except MS SQL AppInsight on a few servers. Previously we had them installed on a lot of servers).  I believe the AppInsight stuff can be a heavy load on SAM, depending on your environment (like if you have a SQL server with 100 databases on it, it's more load that a SQL server with 1 database)

Reinstall rebuild Solarwinds Job Engine v2 - SolarWinds Worldwide, LLC. Help and Support

Repair a failing Job Engine, Collector, and Information service in Orion Platform - SolarWinds Worldwide, LLC. Help and …

The job scheduler database file is corrupt - SolarWinds Worldwide, LLC. Help and Support

Re: MSMQ crashing NPM

Thank you.  This is all great information.