The Computer is Hard to Comprehend? Learn these tips.

We first look for the simplest explanations that are the easiest to check. And after eliminating a possible root cause, we go back to the problem and come up with the next possible cause to check.

So when trying to figure out what’s making a computer slow, the first step is to look into when the computer is slow. If it’s slow when starting up, it’s probably a sign that there are too many applications configured to start on boot. If you want to ask a question-related technology or something like this then Ask Reader is a good platform to get information related to these complex doubts.

In this case, fixing the problem is just a question of going through the list of programs that start automatically and disabling any that aren’t really needed. If instead the computer becomes sluggish after days of running just fine, and the problem goes away with a reboot, it means that there’s a program that’s keeping some state while running that’s causing the computer to slow down.

For example, this can happen if a program stores some data in memory and the data keeps growing over time, without deleting old values. If a program like this stays running for many days, the data might grow so much that reading it becomes slow and the computer runs out of RAM.

This is almost certainly a bug in the program. And the ideal solution for a problem like this is to change the code so that it frees up some of the memory used. If you don’t have access to the code, another option is to schedule a regular restart to mitigate both the slow program and your computer running out of RAM.

A similar problem that can trigger after a long time using an application, and that isn’t solved by a reboot, is that the files that an application is handling have grown too large. So when the program needs to read those files, it gets really slow. Again, this generally points to a bug in the way the program was designed because it didn’t expect the files to grow so large.

The best solution in this case is to fix the bug. But what can you do if you can’t modify the code of the program? You can try to reduce the size of the files involved. If the file is a log file, you can use a program like logrotate to do this for you.

For other formats, you might need to write your own tool to rotate the contents. Another data point that we can use to diagnose what’s going on is whether this happens for all users of the application or just a subset of them.

If only some users are affected, we’ll want to know if there’s something that’s configured differently on those computers that might be triggering the slowness. For example, many operating systems include a feature that tracks the files in our computer so it’s easy and fast to search for them.

This feature can be really useful when looking for something on a computer but can get in the way of everyday use if we have tons of files and not the most powerful hardware. We’ve called out before that reading from the network is notably slower than reading from disk. It’s common for computers in an office network to use a file system that’s mounted over the network so they can share files across computers.

This normally works just fine but can make some programs really slow if they’re doing a lot of reads and writes on this network-mounted file system. To fix this, we’ll need to make sure that the directory used by the program to read and write most of its data is a directory local to the computer.

Hardware failures can also cause our computer to become slow. If your hard drive has errors, the computer might still be able to apply error correction to get the data that it needs, but it will affect the overall performance. And once a hard drive starts having errors, it’s only a matter of time until they’re bad enough that data starts getting lost, so it’s worth keeping an eye out for them.

To do this, we can use some of the OS utilities that diagnose problems on hard drives or on RAM, and check if there’s anything that could be causing problems. Yet another source of slowness is malicious software.

Of course, we always want to keep your computer clean of any malicious software, but we can feel the effects of malicious software even if it isn’t installed. For example, you might have come across a website that includes scripts, either in the website’s content or the ads displayed, that use our processor to mine for cryptocurrency.

Malicious browser extensions also fall into this category. As you can see, there’s a lot of possible reasons that could cause our computer to run slowly. Whenever we have to fix an issue like this, we need to look at what the bottleneck is, figure out the root cause behind the resource being used up, and then take appropriate action. Up next, we’ll do a practical exercise of figuring out why our computer is slow and solving the issue.

A user has alerted us that one of the web servers in our company is being slow, and we need to figure out what’s going on. Let’s start by navigating to the website and loading the page. Okay. We see that the page loads. There is some QnA site that provides a good amount of sources that can help us to get our doubts clear and provide us some unique information.

It seems to be a little slow but it’s hard to measure this on our own. Let’s use a tool called ab which stands for Apache Benchmark tool to figure out how slow it is. We’ll run ab -n 500 to get the average timing of 500 requests, and then pass our site.example.com for the measurement.

This tool is super useful for checking if a website is behaving as expected or not. It will make a bunch of requests and summarize the results once it’s done. Here, we’re asking for it to do 500 requests to our website.

There are a lot more options that we could pass like how many requests we want the program to do at the same time, or if the test to finish after the timeout, even if not all requests completed, we’re making 500 requests so that we can get an average of how long things are taking. Once the test finishes, we can look at the data and decide if it’s actually slow or not. All right. The tool has finished running the 500 requests. We see that the mean time per request was 155 milliseconds.

While this is not a super huge number, it’s definitely more than what we’d expect for such a simple website. It seems that something is going on with the webserver and we need to investigate further.

Let’s connect to the webserver and check out what’s going on. We’ll start by looking at the output of the top and see if there’s anything suspicious there. We see that there’s a bunch of FFmpeg processes running, which are basically using all the available CPUs.