The monitoring of the Local MDrivenServer (cmd: AppCompleteGenericCore.exe -port=5050 -nohttps) shows that the process eats memory up to 1.2Gb regardless of the Model's size.
If I upload the simplest sample model with Class1 and Class2, no viewmodels, no serverside jobs - AppCompleteGenericCore process memory starts from 60Mb (there is no model) and stabilized at the ~1.2Gb (sample model is uploaded).
Could you please advise is it normal behavior?
FYI, I've tried "System.GC.Server": false, "System.GC.Concurrent": false in the AppCompleteGenericCore.runtimeconfig.json - no results.
Thank you!
I deleted my LocalServers folder and downloaded the latest version of MDrivenServer—and the problem disappeared. The old server had CodeDress assembly, so I guess it was a root cause of the memory leak I had.
Related
Running rake searchkick:reindex CLASS=Product for an application causes the Rake process to leak memory; after about 15-20 minutes it's bad enough to freeze a Debian system with 16GB of RAM. There are ~3800 "Product" records.
I managed to work around this problem with the following code in a Rake task:
connection = ActiveRecord::Base.connection
res = connection.execute('select max(id) from products')
id = res.getvalue(0,0)
1.upto(id) do |i|
p = Product.find_by_id(i)
next unless p
p.reindex
end
This is also a little quicker.
Can anyone suggest a means to investigate this memory leak? It would be useful to do so in more detail before considering opening a ticket.
This causes a problem with generating indexes: Text fields are not optimised for operations that require per-document field data
That problem can be fixed by adding the following to the code above:
Product.reindex(import: false)
# Rest of code goes here...
Please, help to solve the problem with communication establishment between PC and 1211C (6ES7-211-1BD30-0XB0 Firmware: V 2.0.2). I feel that I've made a stupid mistake somewhere, but can't figure out where exactly it is.
So, I'm using function TRCV_С...
The configuration seems to be okay:
When i set the CONT=1, the connection establishes without any problems...
But, when i set EN_R=1, I'm getting "error 893A".
That's what I have in my diagnostic buffer: (DB9 - is a block where the received data is supposed to be written)
There is an explanation given for "893A" in the manuals: Parameter contains the number of a DB that is not loaded. In diag. buffer its also written that DB9 is not loaded. But in my case it is loaded! So what should I do in this case?
it seems that DB were created or edited manually due to which they are miss aligned with FB instances try removing and DB and FB instances and then add again instances of FBs with automatically created DBs and do a offline dowonload
I'm using EF6 rc1 with Code First strategy, without precompiled views and the problem is:
If I compile and run the exe application it takes like 15 seconds to run the first query (that's okay, since I'm still working on the pre-generated views). But if I use Visual Studio 2013 Preview to Debug the exact same application it takes almost 2 minutes BEFORE running the first query:
Dim Context = New MyEntities()
Dim Query = From I in Context.Itens '' <--- The debug takes 2 minutes in here
Dim Item = Query.FirstOrDefault()
Is there a way to remove this extra time? Am I doing something wrong here?
Ps.: The context itself is not complicated, its just full with 200+ tables.
Edit: Found out that the problem is that during debug time the EF appears to be generating the Views ignoring the pre-generated ones.
Using the source code from EF I discovered that the property:
IQueryProvider IQueryable.Provider
{
get
{
return _provider ?? (_provider = new DbQueryProvider(
GetInternalQueryWithCheck("IQueryable.Provider").InternalContext,
GetInternalQueryWithCheck("IQueryable.Provider").ObjectQueryProvider));
}
}
is where the time is being consumed. But this is strange since it only takes time in debug. Am I missing something here?
Edit: Found more info related to the question:
Using the Process Monitor (by Sysinternals) I found out that there its the 'desenv.exe' process that is consuming tons of time. To be more specific its consuming time with an 'Thread Exit'. It repeats the Thread Exit stack 36 times. I don't know if this info is very useful, but I saved a '.cvs' with the stack, here is his body: [...] (edit: removed the '.cvs' body, I can post it again by the comments if someone really think its going to be useful, but it was confusing and too big.)
Edit: Installed VS2013 Ultimate and Entity Framework 6 RTM. Installed the Entity Framework Power Tools Beta 4 and used it to generate the Views. Nothing changed... If I run the exe it takes 20 seconds, if I 'Start' debugging it takes 120 seconds.
Edit: Created a small project to simulate the error: http://sdrv.ms/16pH9Vm
Just run the project inside the environment and directly through the .exe, click the button and compare the loading time.
This is a known performance issue in Lazy (which EF is using) when the debugger is attached. We are currently working on a fix (the current approach we are looking at is removing the use of Lazy). We hope to ship this fix in a patch release soon. You can track progress of this issue on our CodePlex site - http://entityframework.codeplex.com/workitem/1778.
More details on the coming 6.0.2 patch release that will include a fix are here - http://blogs.msdn.com/b/adonet/archive/2013/10/31/ef6-performance-issues.aspx
I don't know if you have found the solution. But in my case, I had similar issue which wasted me close to a week after trying different suggestions. Finally, I found a solution by changing my web.config to optimizeCompilations="true" and performance improved dramatically from 15-30 seconds to about 2 seconds.
The pagesize of the file I read is 32768. When i set the JET_paramDatabasePageSize to 32768,JetInit returns -1213.Then,i set the JET_paramRecovery to "Off",JetInit succeeds.But,when I use JetAttachDatabase,it returns -550.
Here is my code:
err=JetSetSystemParameter(&instance,sesid,JET_paramDatabasePageSize ,32768 ,NULL);
err=JetCreateInstance(&instance,NULL);
err=JetSetSystemParameter(&instance,sesid,JET_paramRecovery,0,"Off");
err=JetInit(&instance);
err=JetBeginSession(instance,&sesid,NULL,NULL);
err=JetAttachDatabase(sesid,buffer, JET_bitDbReadOnly );
err=JetOpenDatabase ( sesid, buffer, NULL, &dbid, JET_bitDbReadOnly );
What's wrong with it？I am running a Windows 7 32bit.
The page size is global to the process (NOT just the instance) and is persisted in the log files and the database, so changing the page size can be annoyingly tricky.
Is there information in the database that you're trying to access? Or did you just experience this during development?
If you saw this during development, then the easiest thing to do is to blow everything away (del .edb edb) [Assuming that you kept the prefix as "edb"].
Also, are you sure that the database is 32k pages? You can confirm with esentutl.exe -mh <database-name>.
It will be trickier to recover the data if you do care about, and you switched the page size. (I don't know off the top of my head, and I'd have to try a few things out...)
-martin
I've removed the single Hard Drive (HD) from my VM (Virtual Box 4.0.6) by mistake! :S
I added the HD again, but now it loads with the base configuration (ignoring the state prior HD removal and any snapshot).
I can still see the snapshots tree and they are all there, but I didnt do a snapshot prior to the HD removal..
QUESTION: Is it possible to get the last state up and running again?
I've removed the disk this way (PT language non important):
http://4.bp.blogspot.com/-4iCxcHhqe0M/UISuqMenjII/AAAAAAAAAT8/j726P30_QRA/s1600/1.png
I'm surprised that Virtual Box didn't even give me any warning about loosing data!!
After adding the disk again it acted like described above. And now (I've tried loading the disk directly from the snapshots system folder) it shows some info like this:
http://4.bp.blogspot.com/-BPLxUQxSlx0/UISuswjYd6I/AAAAAAAAAUE/bJ1yfKljUr8/s1600/2.png
[EDIT] - SOLVED:
I've just solved the problem by removing the current HD and adding a new HD from the snapshots folder (the most recent one, in my case a file named something like: fb85e8db-d5f4-46a9-b67b-f8fb39a99a1a.vdi.
There is a .prev file that is created at the VM HDD location.
Sample
<HardDisks>
<HardDisk uuid="{21940e73-1596-45a5-b37e-44cca5d5f1e6}" location="Windows 9.vmdk" format="VMDK" type="Normal">
<HardDisk uuid="{df9d8522-cc5d-499c-b974-037d3f8f89fb}" location="Snapshots/{df9d8522-cc5d-499c-b974-037d3f8f89fb}.vmdk" format="VMDK"/>
<HardDisk uuid="{b707fe0a-f50c-4bc6-b03a-d5a4fe6972fd}" location="Snapshots/{b707fe0a-f50c-4bc6-b03a-d5a4fe6972fd}.vmdk" format="VMDK">
You can add your custom snapshots to that. they are in a tree like fashion and the last one would be loaded. You have to remember the structure too if they were in tree like fashion.
Each snapshot is incremental so make sure the parents and children are in proper order.