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...
Related
It has been over a year since I'm using VSCode. Almost every day I search the web for ways to display the time taken (speed) and space taken(during execution) by my program. This info is very important. But unfortunately, I haven't found(or missed) a way to display these metrics. VSCode is cool to use and lightweight etc. etc., but these metrics were visible by default in some other IDEs (like codeblocks). Some extension or some setting I missed in the many articles I went through. If someone could help me out here, I'll be super grateful.
Thank you in advance
if __name__ == "__main__":
'''
Example code shows to display
the Time and Space taking of the program(creating N_gram language model)
'''
import os, psutil, time
start = time.time()
m = create_ngram_model(3, '/content/train_corpus.txt') # Replace withyour custom function
process = psutil.Process(os.getpid())
print('Memory usage in Mega Bytes: ', process.memory_info().rss/(1024**2)) # in bytes
print(f'Time Taken: {time.time() - start}')
You can add this psutil.Process(os.getpid()) at any function(at main thread to see entire memory usage of the program) that you wish to see the status byprocess.memory_info().rss in the running time Memory usage: 0.5774040222167969. Also check this code for to know the program runtime.
I am trying to get familiar with gem5 simulator.
To start, I wrote a simple program with
int main()
{
m5_reset_stats(0, 0);
m5_dump_stats(0, 0);
return 0;
}
I compiled it with util/m5/m5op_x86.S and ran it using...
./build/X86/gem5.opt configs/example/se.py --caches -c ~/tmp/hello
The m5out/stats.txt shows (among other things)...
system.cpu.dcache.ReadReq_hits::total 881
system.cpu.dcache.WriteReq_hits::total 917
system.cpu.dcache.ReadReq_misses::total 54
system.cpu.dcache.WriteReq_misses::total 42
Why is an empty function showing so much hits and misses? Are the hits and misses caused by libc? If so, then what is the purpose of m5_reset_stats() and m5_dump_stats()?
I would check in the stats.txt file if there are two chunks of
---Begin---
---End-----
because as you explained it, the simulator is supposed to dump the stats at dump_stats(0,0) and at the end of the run. So, it seems like you either are looking at one of those intervals (and I would expect the other interval to have 0 for all stats); or there was a bug in the simulation and the dump_stats() (or reset_stats())didn't actually do anything. That actually happened to me plenty of times, but I am not really sure as to the source of this bug.
If you want to troubleshoot further, you could do the following:
Look at the disassembly of your code and find the reset_stats.w and dump_stats.w
Dump a trace from gem5 and see if it ends up executing the dump and reset instructions and also what instructions (and how many) are executed before/after.
Hope this helps!
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.
I can't put my finger on why it's doing this, but since a few days help takes a lot of time to show. Either inline (selecting a function, selecting "help for"), or by using the commands doc or help. The command doc cmdname takes about 10 seconds to show the help window. I did, taking fwrite as example, try profile on;doc fwrite;profile viewer and digging through the rabbit hole I arrived on a private java matlab method which is taking forever:
tic;
com.mathworks.mlwidgets.help.HelpUtils.getDocCommandArg('matlab\fwrite', true);
toc
Elapsed time is 9.993832 seconds.
Any idea what could be causing that issue? It also happens in safe mode, with no other running programs than MATLAB. I'd try a complete reinstall of MATLAB, but if I could avoid that that'd be great.
There are a couple of things that might be contributing to this issue, but given the information you've provided it's hard to say exactly what is going on.
When the R2012b help system initializes, it does a few tasks that can sometimes introduce a noticeable delay, mostly related to determining which MathWorks products are available and how you have your help preferences set up. 10 seconds would be unusual, but there is a possibility that this is what's causing the delay. If you're seeing the performance hit on your first use of the help system, but not again in the same MATLAB session, this is the likely cause. This behavior is improved in R2013a.
Other than initialization tasks, the Java call in question is a relatively straightforward search against the same search index that is used for searching the documentation. If you are finding that searching the documentation in the help browser is slow, this would be a hint that the performance issue lies somewhere within the help system's search functionality.
In either case, your best bet is probably to contact MathWorks technical support. It is likely that we can take a closer look at this and possibly come up with some sort of fix.
The problem has been solved with input from mathworks support:
>> tic;doc fwrite;toc
Elapsed time is 20.301202 seconds.
>> tic;reader = org.apache.lucene.index.IndexReader.open(fullfile(docroot,'helpsearch'));
searcher = org.apache.lucene.search.IndexSearcher(reader);
term = org.apache.lucene.index.Term('relpath','ref/plot.html');
query = org.apache.lucene.search.TermQuery(term);
hits = searcher.search(query);
fprintf('Found %d results\n', hits.length); searcher.close; reader.close; toc;
Java exception occurred:
java.io.IOException: Lock obtain timed out:
Lock#C:\Users\b\AppData\Local\Temp\lucene-ca3070c312bc20732565936b371a8bd3- commit.lock
at
org.apache.lucene.store.Lock.obtain(Lock.java:56)
at
org.apache.lucene.store.Lock$With.run(Lock.java:98)
at
org.apache.lucene.index.IndexReader.open(IndexReader.java:141)
at
org.apache.lucene.index.IndexReader.open(IndexReader.java:125)
After that, thinking it was a problem with a temp file being locked, I closed Matlab, went into AppData\Local\Temp\ and cleaned all the temporary files in it.
>> tic;
reader = org.apache.lucene.index.IndexReader.open(fullfile(docroot,'helpsearch'));
searcher = org.apache.lucene.search.IndexSearcher(reader);
term = org.apache.lucene.index.Term('relpath','ref/plot.html');
query = org.apache.lucene.search.TermQuery(term);
hits = searcher.search(query);
fprintf('Found %d results\n', hits.length); searcher.close; reader.close; toc;
Found 5 results
Elapsed time is 0.106868 seconds.
>> tic;doc fwrite;toc
Elapsed time is 0.153808 seconds.
Either it's the cleaning the temp files or the reference to internal java classes org.apache.lucene* that did the trick, but here it is, now doc is fast again.
(Update to answer Jonathan Leffler's question below):
We're running Perl 5.8.7 and Oracle 11.1.0.7.0.
Due to the company's policy, developers have no arbitrary control in regard to software upgrade. Giving the proposal to the upper management takes months to be followed up (if approved) - I guess it's not a surprisingly odd situation for several other companies too.
I inherited the program from someone else left the company and found the warning about "issuing rollback() ..." from the application log file. The actual problem "maximum open_cursor exceeded" was found after I run DBI_TRACE=2=/tmp/trace.log program_name.pl.
Looking at the number of $dbh->{ActiveKids}, $dbh->{Kids}, and $dbh->{CachedKids}, I assume the maximum open cursor is 50 as the error happens after it reaches 50.
Our legacy production codes are using these modules:
DBI - 1.48
Ima::DBI - 0.33
Class::DBI - 0.96
Class::DBI::Oracle - 0.51
DBD::Oracle - 1.16
For some odd policy reason, upgrading the module to a newer version is not possible :(
The application relies on using CDBI to handle relationships on a large number of tables. A simplify snippet of the code is as below:
JOB:
foreach my $job (#jobs) {
my #records = $job->record;
RECORD:
foreach my $record (#records) {
my #datas = $record->data;
DATA:
foreach my $data (#datas) {
....
}
}
}
where each #jobs, $record, and $data is an object to a table and the inner most loop calls several other triggers.
Somewhere after several loops I'm getting an Oracle error: maximum open_cursor exceeded and then I got the error from the CDBI: issuing rollback() for database handle being DESTROYE'd without explicit disconnect.
I can workaround it by undef-ing the DBI CachedKids on the most outer loop, with:
# somewhere during initialization
$self->{_this_dbh} = __PACKAGE__->db_Main();
....
JOB:
foreach my $job (#jobs) {
RECORD: ....
DATA: ....
$self->{_this_dbh}->{CachedKids} = undef;
}
Is that the proper way to do it?
Or does CDBI support a way to clear statement handle the same way as DBI $sth->finish() ?
Thanks.
At some point, you will have to explain why you cannot upgrade to more nearly current versions of the software. You didn't mention which version of Perl you are using, or which version of Oracle; somehow, I suspect that it is neither 5.10.1 nor 11gR2.
Current versions:
Class::DBI 3.0.17
Class::DBI::Oracle 0.51
DBI 1.609 (version 1.48 is from 2005)
DBD::Oracle 1.23 (version 1.16 is from 2004)
Ima::DBI 0.35
What changed recently? Why are you suddenly finding problems in a piece of software that was, presumably, very stable? Is this new code?
With plain DBI, when you undef a statement handle (by having it go out of scope, for example), then the resources associated with it are released - more or less noisily. However, there is enough infrastructure between Class::DBI and DBI that it is hard to tell how this might map.
Have you worked out what the limit on open cursors actually is?
Have you worked out whether you've opened enough cursors to actually exceed that limit?
Have you tried running with DBI_TRACE set in the environment? A value such as 3 will tell you a fair amount about what it going on - maybe too much. It would show whether cursors are being released properly or not.
Have you tried reducing the number of tables manipulated in a single session?
Have you considered disconnecting and reconnecting between manipulating tables?
Is there a way to get to the statement handle corresponding to the Class::DBI abstractions, so that you can in fact execute $sth->finish()?