1) By Archiving a process will there be considerable impact on memory consumptio

1.) Archived processes that successfully archive no longer take up any RAM, what they take up is HD.  Luckily, absolutely enormous HDs are extremely cheap.  Archiving is very recommended for all your processes to aid in tracking down bugs.  If you feel the need you can select some processes that have very few errors and remain quite stable for deletion to free up some HD space.  With good server hardware it shouldn't be necessary to do that for quite a long time.

1 b) Are there any other ways to improve memory usage?  Here are some:

Keep your process variables small

Your process history keeps the state of each PV at the beginning and end of every script task.  Therefore, if you do several operations on the same PV, try to do all operations in the same place, or as few places as you can.  That way only one or two versions of it get saved.

Avoid deeply nested subprocesses.  Every sub-process runs on the same process execution engine as it's parent.  The whole stack is on the same box.  If you can use startProcess, that can be load-balanced onto another box.

If you aren't going to use the output of a subprocess for anything, use startProcess or asynch, move on, and get the parent ready to archive.

Make your queries such that they filter as much data out as possible.  Send the smallest amount of data you can back from your database to Appian.  You might be tempted to get all the records, store them in a PV, then use Appian to filter out the one you want to display.  Don't do this.  Your RDBMS is much better at filtering, will do it much faster, and you'll have less in your Appian's RAM.

Do not save storedValues unless you are actually going to use it later in the process.  You can look in your database to see if it was stored correctly.

You can use many subprocesses at the same level, especially for a long-running process.  That way, the bulk of the running process can already be on it's way to being archived before the whole thing is even done.

Send as little data as possible to your subprocesses, and return as little data as possible back.  If you have a CDT with 35 data elements in it, and you want to send the whole thing to your subprocess even though you know you're only using 2 fields, don't do it.  Send only those 2 in separate variables.

Do everything you can asynchronously.  Avoid all waiting it is possible to avoid.

Avoid as much MNI as possible.  Node instances can be fairly big, and every one of them stays in memory until the process archives.  Use a!forEach as hard as you can.

Make sure abandoned tasks eventually time out, and the process archives.

Shorten the system-wide default for archival time down a few days if you have persistent memory problems.  Usually any problems you have to triage will result in errors that prevent the problem processes from archiving anyway.

2.)If a process has active nodes (surrounded by green and still performing whatever operation), the process won't end when it reaches a regular End Node.  End Node behavior can sometimes be a little unexpected, so Appian best practice is that every process model feature at least one Terminate Node.  That stops any Active nodes in the middle of what they were doing and kills the whole process. 

End Node without set to Terminate should be specifically for a process branch that has done all it needs to do, but other parts of the process should finish what they're doing too.  When you want the flow here to stop without stopping what's going on over there, making sure everything finishes up before you move on.  It should be used to eliminate race conditions.

1.) Archived processes that successfully archive no longer take up any RAM, what they take up is HD.  Luckily, absolutely enormous HDs are extremely cheap.  Archiving is very recommended for all your processes to aid in tracking down bugs.  If you feel the need you can select some processes that have very few errors and remain quite stable for deletion to free up some HD space.  With good server hardware it shouldn't be necessary to do that for quite a long time.

1 b) Are there any other ways to improve memory usage?  Here are some:

Keep your process variables small

Your process history keeps the state of each PV at the beginning and end of every script task.  Therefore, if you do several operations on the same PV, try to do all operations in the same place, or as few places as you can.  That way only one or two versions of it get saved.

Avoid deeply nested subprocesses.  Every sub-process runs on the same process execution engine as it's parent.  The whole stack is on the same box.  If you can use startProcess, that can be load-balanced onto another box.

If you aren't going to use the output of a subprocess for anything, use startProcess or asynch, move on, and get the parent ready to archive.

Make your queries such that they filter as much data out as possible.  Send the smallest amount of data you can back from your database to Appian.  You might be tempted to get all the records, store them in a PV, then use Appian to filter out the one you want to display.  Don't do this.  Your RDBMS is much better at filtering, will do it much faster, and you'll have less in your Appian's RAM.

Do not save storedValues unless you are actually going to use it later in the process.  You can look in your database to see if it was stored correctly.

You can use many subprocesses at the same level, especially for a long-running process.  That way, the bulk of the running process can already be on it's way to being archived before the whole thing is even done.

Send as little data as possible to your subprocesses, and return as little data as possible back.  If you have a CDT with 35 data elements in it, and you want to send the whole thing to your subprocess even though you know you're only using 2 fields, don't do it.  Send only those 2 in separate variables.

Do everything you can asynchronously.  Avoid all waiting it is possible to avoid.

Avoid as much MNI as possible.  Node instances can be fairly big, and every one of them stays in memory until the process archives.  Use a!forEach as hard as you can.

Make sure abandoned tasks eventually time out, and the process archives.

Shorten the system-wide default for archival time down a few days if you have persistent memory problems.  Usually any problems you have to triage will result in errors that prevent the problem processes from archiving anyway.

2.)If a process has active nodes (surrounded by green and still performing whatever operation), the process won't end when it reaches a regular End Node.  End Node behavior can sometimes be a little unexpected, so Appian best practice is that every process model feature at least one Terminate Node.  That stops any Active nodes in the middle of what they were doing and kills the whole process. 

End Node without set to Terminate should be specifically for a process branch that has done all it needs to do, but other parts of the process should finish what they're doing too.  When you want the flow here to stop without stopping what's going on over there, making sure everything finishes up before you move on.  It should be used to eliminate race conditions.