Extremely Slow Querys, after a windows restore point - performance

A few days ago, one of my costumers who has(MariaDB 10.3.10) installed in windows 10, had a power issue on hes computer, after he turned on the computer again, windows pop'd the restore point option for him and he took it, before that, hes data base was working correctly as intended, but after he used the restore point, something happened, and some store procedures, went from 5-10 seconds, to 3-4 minutes.
My first thought was that some tables were corrupted, but afer some test, i decided to make a dump and install the Data in another computer with the same database engine version(MariaDb 10.3.10) and surprisingly, everything worked perfectly, i took the same database, in other 2 different computers, and everything ran correctly, no slow querys nothing, i decided to format the computer with the issue, and installed everything from scratch, but nothing changed, same issues, same problems...
Any thoughts on this=

Related

Is there a way to cap the file size of slony log shipping files?

I am working with a SuSE machine (cat /etc/issue: SUSE Linux Enterprise Server 11 SP1 (i586)) running Postgresql 8.1.3 and the Slony-I replication system (slon version 1.1.5). We have a working replication setup going between two databases on this server, which is generating log shipping files to be sent to the remote machines we are tasked to maintain. As of this morning, we ran into a problem with this.
For a while now, we've had strange memory problems on this machine - the oom-killer seems to be striking even when there is plenty of free memory left. That has set the stage for our current issue to occur - we ran a massive update on our system last night, while replication was turned off. Now, as things currently stand, we cannot replicate the changes out - slony is attempting to compile all the changes into a single massive log file, and after about half an hour or so of running, it trips over the oom-killer issue, which appears to restart the replication package. Since it is constantly trying to rebuild that same package, it never gets anywhere.
My first question is this: Is there a way to cap the size of Slony log shipping files, so that it writes out no more than 'X' bytes (or K, or Meg, etc.) and after going over that size, closes the current log shipping file and starts a new one? We've been able to hit about four megs in size before the oom-killer hits with fair regularity, so if I could cap it there, I could at least start generating the smaller files and hopefully eventually get through this.
My second question, I guess, is this: Does anyone have a better solution for this issue than the one I'm asking about? It's quite possible I'm getting tunnel vision looking at the problem, and all I really need is -a- solution, not necessarily -my- solution.

Hadoop FileSystem.getFS() pauses for about 2 minutes

I'm having a very strange problem. I'm using dfs-datastores Pail abstraction to write data to HDFS in Java. I don't think the Pail piece is important to the problem though.
When it calls org.apache.hadoop.fs.FileSystem getFS(java.lang.String path) with a path on my local filesystem it pauses for about 2 minutes seemingly doing nothing then returns. This is on my laptop.
The weird thing is that it worked really fast when I was on the network at my office today, but now that I'm home it's doing it again. I'm running Ubuntu 10.10 64-bit with Java 1.7.
Anyone have any ideas what it's doing? What could be different between being at work and being at home?
UPDATE:
I've been stepping through code with the debugger and it seems to be having trouble in Configuration.loadResource(). It's calling that multiple times and it will take 5-10 seconds to return from that function.
UPDATE2:
I've narrowed this down a little further. The biggest hang up seems to be when it calls KerberosName.setConfiguration(). Which would explain why it runs fast at work since the Active Directory acts as a Kerberos server. I don't have one here at home, so it can't find one. Now they question is why in the world it's trying to load the Java Kerberos stuff.
I found a solution (or at least a work around). I installed the krb5-kdc package and now my little program runs fast without any unexplained pauses. After this I removed krb5-kdc, tested and it was still running fast. I removed /etc/krb5.conf and it started doing the pause again. It looks like using the Hadoop library on Ubuntu (at least) requires a /etc/krb5.conf file.
Maybe this will help someone else.

Entity Framework takes 30 minutes to generate a model

No matter what I do, which DB I connect with, EF seems to take around 15-30 minutes to generate a model. While it's doing this, I get a "Visual Studio is busy" message in the system tray.
The first DB I connected to was complex and had a lot of data, lots of views so I thought, may be that's why. Now I have a local DB file with 1 table that has 2 columns and 3 rows. It still takes the same amount of time.
Eventually VS crashes and restarts. Has anyone had this problem before? Any idea?
I've looked at resource monitor, devenv.exe does not seem to be consuming any resources that would indicate it's doing a lot of work.
What credentials do you use to access your DB? Let's try ruling out domain latency issues first. If this is at work, can you verify the same flow on 2 separate machines using the same domain credentials? This wouldn't apply if you were using local creds.
Turns out I had a Visual Studio DVD in my DVD drive. Each time I did something with EF, VS started to read from the disc. I have no idea what or why, but the little LED would blink. Once I ejected the disk, everything ran fine. Go figure!

Autoconf on Windows 7 dreadfully slow

I am working on a project using Google's cmockery unit testing framework. For a while, I was able to build the cmockery project with no problems. e.g. "./configure", "make && make install" etc. and it took a reasonable amount of time (1-2 minutes or so.) After working on other miscellaneous tasks on the computer and going back to re-build it, it becomes horrendously slow. (e.g. after fifteen minutes it is still checking system variables.)
I did a system restore to earlier in the day and it goes back to working properly for a time. I have been very careful about monitoring any changes I make to the system, and have not been able to find any direct correlation between something I am changing and the problem. However, the problem inevitably recurs (usually as soon as I assume I must have accidentally avoided the problem and move on). The only way I am able to fix it is to do a system restore to a time when it was working. (Sometimes restarting the machine works as well, sometimes it does not.)
I imagine that the problem is between the environment and autoconf itself rather than something specific in cmockery's configuration. Any ideas?
I am using MinGW and under Windows 7 Professional
Make sure that antivirus software is not interfering. Often, antivirus programs monitor every file access; autoconf accesses many files during its operation and is likely to be slowed down drastically.

why is vs2010 so slow lately? Its nearly unusable

Not sure what has happened on my dev machine but I can barely use visual studio 2010 these days. I have a copy of professional edition installed on a win7 pro x64 build running on top of a i5 M430 and 6 gigs of ram.
With only VS2010 open i've seen the process leak away to 600,000k+.
The editor is extremely slow. Every character I type sends the gui into "Not Responding" for 5 seconds and starting/stopping the debugger is a ~30 second operation.
I've done a repair install. No change.
I've removed productivity power tools and installed the perfwatson extension.
When I installed perfwatson the GUI sped up a bit while opening/loading a project. But the text editor still has an awful delay.
What else can I do? Harware rendering is off in my environment options.
an example of the slowness (literally): typing Height="1024" takes about 30 seconds to display in the text editor and do its update flash to go out of not responding. The word "Height=" takes 5 seconds to show. The intellesense and blank " " takes another 5 seconds. Each digit pops in every five seconds after that.
Needless to say even trying to edit existing work is a frustrating experience.
edit: rolled back one version on video driver. No noticeable changes after reboot.
edit: did some winforms projects today. No slow issues with this project type. Must be something with just wpf/sl projects.
edit 8/18/11: Took troublesome project to the production server. VS2010 editor works great there. Very snappy and responsive. Not at all slow. So it's not something inside my project. It's something in my machine. But a full out OS rebuild is something I can't just do now. Probably will start a bounty soon.
Delete the .sdf and .sou that have the same base file name as your solution file.
If your solution file is
c:\MyProject\project.sln
You should delete
c:\MyProject\project.sdf
c:\MyProject\project.sou
This solves 98% of the problems of slow VS.
These files contain intermediate information that is not important for the functionality of the solution and as time goes by they swell up and become bloated and fragmented. VS relies on these files for and if dealing with them is slow, everything is slow.
I know this is an old post but I have just had an issue where my visual studio project has been working fine for about 2 1/2 years and suddenly every time I clicked run I had to wait about 3 minutes and the same when clicking stop. I tried the old windows reboot but to no avail.
I found a post about deleting the projects .suo file (it was only 4MB).
I deleted the .suo file and everything is completely back to normal. I guess the file had corrupted or something.
Having a large number of breakpoints or a large number of files open can cause serious performance problems, but it sounds like your problems are worse than that...
A bios update and a intel chipset update on my machine solved nearly all my performance issues.
The slowness started to creep out into the OS and I was pegging the cpu at idle. I've got 4 cores and 8gb ram. It shouldn't do that. Now its happy at 8% load at idle.
Thanks to those that tried to help.
had the same problem. not sure what causes this ridiculous performance nightmare, but eventually i had to re-install windows. This same issue was posted on Microsoft forums but the best answer was to re-install VS or windows.

Resources