Hi Guys, I've been having something strange with my VPS Amibroker for the last days. After an AMI crash while opening two AMI instances with two different databases, and after restarting the system, I've noticed that the AmiBroker running the Real-time database (IQ Feed) is consuming much more resources than before. It used to be at 30-40% CPU usage, but now it's at 90% or more.
I read it could be a corrupted file, so I deleted the Broker_newcharts and Default_layout files and rebuilt the layout, but nothing happens. I've also noticed something really strange, when I open AMi, a series of ticket windows, that aren't from the layout I have, appear in cascade for a second, and then they disappear immediately. Leaving only the valid ones and without being able to see any traces of them.. I think there must be file causing this problem. Which files should I check/delete? Ami version is 6.93. Here is the Perf, Monitor
Any tip?
Display chart timing in Tools - Preferences - Misc. Either you have much more data than before or formulas are inefficient or they use more bars than really needed. Check QuickAFL, unnecessary calls to SetBarsRequired and formula/chart timings and Database settings. The Users Guide has an article on performance.
Hi Tomasz, Yes i have already done all this. The thing is nothing changed... Same Layout, same Formulas, same DB, but after Hanging resources consumption more than doubled...I have also thought about whether it is or not a VPS problem..
So, could there be some configuration file involved in this issue that I can delete to check it??
Of course i have also reinstalled AMI, maintaining Layouts but nothing changed..
Sure. I also thought that. But i have other AMI on the same VPS with different BD (EOD) and and this has not been affected. Only the Real Time AMI has been affected. Weird..
No it is not weird. Obviously EOD database does NOT generate automatic refreshes when new data come in. Also different VPS shares might have different allocation of resources, one might have higher vCPU/vRAM/disk allowances than the other.
Yes, I check Chart Performance a regular Basis, mainly because it runs on a VPS 24/7 and resources must be optimized. My Strategies have buttons for deactivate any consuming Plots or Visual Info that can be too intensive. I use Chart Timing and others regularly and now CT is double than before. It has increased since the crash, in line with processor usage.
You are right that RT BBDD is much more intensive than EOD BBDD. I also raised the Time refresh Interval (before was on 0) but nothing changed.
So i suppose a common issue on any corruption of any AMI main files can be discarded as it it affects only to RT Database and its folder? Maybe their Broker files??
AmiBroker by itself does NOT "disintegrate" or "run slower". It is just machine code fully deterministic. It works THE SAME all the time.
There is ALWAYS a reason that is NOT directly AmiBroker related.
As I wrote already: AMOUNT OF DATA that you process - check the NUMBER OF BARS. That's the simplest reason for increased processing time - if number of bars has increased, the more data is to process
Also, if that is only for charting make sure that QuickGFX is enabled.
There are no other reasons in AmiBroker. All other reasons are outside (hardware changes / issues like CPU overheating / power supply issues / VPS overload (other users).
Yes, sure Tomasz. My question was just to know if any AMI file could have been corrupted by the Crash, and so caused this drop in performance. As the AFL´s were exactly same as before. All the stuff for KPI AFL and Charts Performance i know it and use it. It´s required to keep all systems at an acceptable load 24/7 on the VPS. But this was different.
Anyways, what i´ve done is reoptimize a little bit to reduce processor time, although this wasn't necessary before, and Over all! talk to the VPS people in case they are stealing cycles from me since the crash.. and that may even have been the cause of the Hang.
PD. Any recommendation on VPS providers? I've tried several of them and they're all a bit pirates..
thanks!
I don’t know if anything was corrupted at all. It is unlikely. I see no reason why it would be, but you can delete many files and it will refer to default settings. For example you can delete broker.prefs and preferences would refer to defaults.
thanks Tomasz, Finally, what worked for me was restoring an old backup of the Broker.newcharts file and rebuilding the layouts. This returned the CPU times to what they were before. I also tried deleting Broker.prefs to reset the preferences, but curiously the times skyrocketed again.. so i returned to my own version.
