I have been working with the Inductive team for about a month trying to resolve this issue, namely Alex and James. Thanks guys!!! At first we didn’t know why the Gateway kept crashing. Our first breakthrough was in noticing that Ignition places certain files in /tmp that were taking up an enormous amount of space. The lion’s share of storage had been given to the Ignition specific directories as they were expected to see the most fluctuation in size. No problem we allocated more space to the /tmp directory. The problem files ate up the extra space within hours. So more research and we discover that the uncontrolled files are of this structure:
imageio123456789065438972.tmp
One is created for each mobile client launched and it is destroyed with that client. It appears to be the Java imageio file containing the ignition splash screen and deleting it, even a secure delete, does not appear to offend the running client. So while waiting for some more info from James I attempted to do a short term fix by simply deleting the obnoxious files if they were found to be present every half hour. 
This upset the gateway because it crashed about 6 hours later. Instead of getting rid of the trouble makers I was orphaning them in the server. I did think that if I tried to secure delete them on a schedule it might work but this is bad practice and will probably create more problems. It was mentioned to me that perhaps another portion of the Ignition software looks for those files as a trigger for other processes and my deletion of them may disturb the environment as well. We are using Ubuntu 12.05 and I am even considering upgrading to 14 at this point even though I have not been all that pleased with my experiences with Ubuntu14. My noggins twisted and I’d appreciate some advisement.
Here is an update to my problem. I have gathered enough samples of the hourly size and existence of the imageio files in the /tmp folder to notice a trend. One of the imageio files was consistently outgrowing the others. With a little investigative work I was able to pair up each of the projects with their appropriate imageio file. I was shocked to find that the project with the least tags reads and writes was the monster. The only difference between it and the others was that it contained a graph. So I removed the graph and it’s growth dropped by 93%. Boooo! no more pretty graph. Boss not pleased RRRRaawwwwrrrr!!! I am now monitoring to see when and if Java will do some garbage collection on these files or if I have just slowed down the inevitable.
It was recommended that I slow down the request time of the chart to 30 seconds I.E. the part of the start and stop date expression that uses the now() function should be changed from now(100) to now(30000). I was hopeful that this would indeed solve the growth problem of the file. Unfortunately it did not. 
Been busy so it took me a minute to get back and give some resolution to my situation. Mr. James Hunt and I discovered that my problem was not an Ignition problem but rather a design issue with Java’s JVM. If you are using the mobile clients in deployments that are treated like any normal app you should never run into the issue I did. We run ours like miniature HMI’s and our factory runs 24/7. James teased me with the idea that there may be native iOS deployment capabilities for enterprise clients in a later version of ignition 
In the meantime my boss made me start learning Swift to convert our mobile deployments to native applications. I have almost finished and it wasn’t too bad but it would have been easier to do everything in one place.