Real Time CustomRatesUpdate() Eat A Lot Of Disk Space !!! - page 2

New comment
 
Soewono Effendi #:
Try to run it over longer period and verify the information again.

You might want to verify file size in the custom folder:

<DATAFOLDER>Bases\<CUSTOM FOLDER>\history\<CUSTOM SYMBOL>\

and

<DATAFOLDER>Bases\<CUSTOM FOLDER>\history\<CUSTOM SYMBOL>\cache\


Notice there are .hcc custom symbol folder and its *.hc files in the cache folder.

Good luck.

Do you understand the problem here? The problem is that the .hcc file is too large after a period of running. I don't know if you understand what I said above or not.

 
Le Minh Duc #:

Do you understand the problem here? The problem is that the .hcc file is too large after a period of running. I don't know if you understand what I said above or not.

well, in your opinion, how large should the file be ?
Do you have any comparisson ?


You might want to check your file system sector size too.



Please also refer to:

 
Soewono Effendi #:
well, in your opinion, how large should the file be ?
Do you have any comparisson ?


You might want to check your file system sector size too.



Please also refer to:

I don't understand what you want to say here, can you explain in more detail? And what is the solution when I run 20 custom symbol pairs and consume ~60GBs of disk space/day?

Is there any admin here who can explain it to me? Why is the data when running the default symbol much lighter than the custom symbol when running the CustomRatesUpdate() function in real time?

 
Hi!
I have the same problem when working with CustomRatesUpdate() and CustomRatesReplace() in real time.
I have about 100 charts running at the same time. 1 GB of memory accumulates in a minute.

Did you manage to solve the problem somehow? It shouldn't be like this...
The history file should be updated correctly, and not accumulate unclear information of large sizes
 
Andrei Serganov #:
Hi!
I have the same problem when working with CustomRatesUpdate() and CustomRatesReplace() in real time.
I have about 100 charts running at the same time. 1 GB of memory accumulates in a minute.

Did you manage to solve the problem somehow? It shouldn't be like this...
The history file should be updated correctly, and not accumulate unclear information of large sizes

This is a terminal problem, you cannot " fix" it without side effects. Or you can just pray that the dev team pays attention to this issue and fixes it

12
New comment