Forgot to mention: Under WinXP, by mid afternoon response was so slow that clicking on a chart stop order line wouldn't select the line. After several seconds, moving the mouse onwards to check out if a chart order button would work, the up/down arrows of order-line selection took over as the mouse cursor while the mouse was over a button. After a second and a half, the button clicked itself and an order was processed! Java notes mouse button-down and button-up, so there appears to have been a bit of a lag between the button-down over the chart order-line and Java asking "where is the mouse", resulting in "over the button"? and then the buffered button-up triggering the button? scary the first time it happened, even scarier when I could replicate it...
So, the next solution was to go for upgraded hardware. Not as easy as learning Java Console, tunning the system, running under server Java and from batch files with additional Java parameters set, but it is an immediate solution that can be tried, although you have to throw money at it. hardware: Xeon W3520 quadcore CPU (eight virtual cores) 4G DDR3 1600 7-8-7-20 (4G for now to keep the comparison close) Asus Sabertooth X58 motherboard ATI/AMD 5750 (for two monitors) Nvidia 430 (for two more monitors) Same hard drive with Win7 on it as ran on the 9450. Loaded, changed drivers to the new motherboard, added the ATI driver, rebooted and away we went. What a difference. Astoundingly faster response, everywhere across the TWS platform. Load is more even across the cores, sparser, three low load at 2% peaking regularly at 5%, another just above idle, another with loads varying between 12% and 30%, depending on charts, with a fifth core popping up to 15% with some actions. Chart Trader button order with an auto-stop populates the order tables in around a quarter second with full painting across all three charts in sequence completing in under 3/4 second from the original click of the button. One core will peak to 8% for this. Going click happy on 10+ orders (plus stops) and the order tables keep up the same response, with charts lagging up to a second (appears priority is given to new orders going to tables over updating charts, but it's so fast it's hard to tell!!!). Tried 20 orders. Same response. Worst loaded core peaks to 40% for this. Will test again under market load. 1:00 p.m. after being open before the market, and the response is largely the same, with a slight lag that is so small that I can't quantify it. Click happy on 10+ orders gets a very temporary peak of 80% on the one core. Other cores get a barely detectable rise that immediately falls back. Through the click happy, charts stay updated, with noticeable milli-second lag on the one second line charts, with no detectable lag on Book Trader Level II for aapl or rimm, but I haven't another feed to compare to, to know for sure. 3:00 p.m. Same responses as at 1:00 p.m.. Circling the mouse still pops the one core, but is limited to 60%. ;-) I've bought myself some great response from TWS and some time to learn Java Console.
What version of Java are you using now? Still 1.6.23? I have been using 1.6.0_xx for a long time and have never seen anything similar to the performance problems you are having. I run multiple versions of TWS on a single box and the CPU utilization for Java never goes above about 1 or 2%. I tried the mouse circling you mention and it doesn't do anything to the CPU. You might try downgrading your java (newer is not always better) and see if that helps at all. The same goes for TWS... I'm still on 908 and am always reluctant to upgrade until I have really tested out the newer versions. Good luck.
Well, I couldn't resist a very modest overclock from 2.67 to 3.2GHz. And the results are: OMG. Order creation completes so fast I can't tell how fast it is, except that it is well under a quarter second. The Chart Trader button order with an Auto Stop is populated across the two tables and displayed in turn upon three charts, completing the final chart noticeably under a quarter second from the original click! Occasionally, there's lag between the order appearing on the 2nd chart and the final chart, taking noticeably longer, but still completing just under a quarter second from the original click. Going click-happy with 20+ orders as fast as I can click and it maintains the above response, except that the final chart can take up to a half second to catch up after the final order is populated. All while market data and indicators are all maintained on charts with no detectable lag, as is the Level II for two Book Traders. Since going to Win7 and the W3520, no more charts stopping updating at the leading edge. I can't envision it being any faster. It's the brute force solution to a slow TWS, but it sure works! With stock CPU heatsink, core temps between 45C and 54C running TWS with market loads. Between 42C and 48C with my usual computer use loads.
I just submitted this bug report. Tittle: Memory loss in Javaw.exe with charts Steps: Clean install Win 7 64 bit. Install latest Java runtime 1.6.0_24 Instal TWS 914.8 Open a chart. Change to 2 weeks 30 Min. Change to 3 weeks 30 min. Change back and forth. Watch the Javaw.exe memory usage in the Task manager Result: Everytime you change back to one of them, not both, memory usage increases about 50 Mb. Expect: Worst case, the memory usage shoud stay constant after view each one. Better case, some sort of memory management to keep total Java VM lower. Notes: Installed Jave 64 bit on top of 32 bit. Same results -- Uninstalled TWS, Java 64 and 32. Did a reg clean up. Then installed 64 bit Java only: Same results. --Interestingly the max heap for Java defaults to 512M. After you hit about 1.5x that amount TWS becomes unresponsive and the Java exe pegs the CPU as if it is page swapping. Changing the heap to 1024 helps but I still exceed the 1.5x of 1024 during daily usage and TWS needs to be rebooted. -- This issue did not occur before the new charts. Config: Build 914.8, Feb 15, 2011 12:10:59 PM Jolt Build 1.1.7, Sep 9, 2010 02:19:30 PM Nia Build 1.7.7, Aug 6, 2010 02:35:40 PM ModelNav Build 1.1.29, Oct 5, 2010 08:32:30 AM Java Version: 1.6.0_24 OS: Windows 7 (x86, 6.1) =============== I can get to 1.5 gb of memory usage by days end with 6 charts and one switching between various contracts.
I'm running into the same problems now in 2016. I just watch about 40 charts in the morning and then trade with 18 booktraders open( slow moving ), and TWS gets slower and slower during the day. At the end of it, it takes about 2-5 s to update an order... Now, it is not possible anymore to change the capacity in the shortcut link. Is their some quick fix to increase the memory allocated to TWS?
Look in the shortcut. Go to the location of tws.exe. Edit "tws.vmoptions", which is where the java virtual machine options are stored for use by tws.exe.
Hello Canoe, Thanks for answering after 5 years...I am running Build 950.2g from May 2015. I guess the file is named StartTWS on this build. There is the same line. But they told me at IB to change the number 768 to 1512, but TWS wouldn't start at all at 1512? What is the problem?
I trust you saved a copy of the file before you changed it. Compare to see if you changed anything else by accident. Also, did you provide the correct unit specifier ("k", "m", "g"). If IB's recommended value didn't work, I suggest you take it up with them. By "the number 768", does that mean you're adjusting the maximum heap size? -Xmx768m Specifies the maximum size (in bytes) of the memory allocation pool in bytes. This value must be a multiple of 1024 and greater than 2 MB. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, g or G to indicate gigabytes. If you're going to be changing the parameters of the Java Virtual Machine (JVM), you should have some understanding of the JVM and what & why you're changing. I'd suggest you start here: https://ibkb.interactivebrokers.com/article/2170 You should probably take a look at: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html and http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html If you're writing your own Java code to work through TWS or gateway, I found useful: Optimizing Java, Evans and Gough, Chapter 2 'Overview of the JVM'
Thanks a lot Canoe. I will watch all these links to understand how it works. Yes IB reps told to change heap size to 1512, and then 1200...which I found odd since I thought as well it should be a multiple of 512. Whatever...It works perfectly with 1200. I hadn't modified anything by error.