I am new to using Linux.
The process lib/systemd/systemd-journald is taking up 30-60% of my CPU. I don't know how to stop it. And I do not know how to look for the problem.
This is a process for the system's journal. Someone ever was hit by this issue too, which might be related to your system's file changing too fast.His solved it by deleting the file ".kde4/share/apps/nepomuk",you can have a try.
Related
I am having an issue with a relatively small openstack cluster deployed with kolla-ansible. The issue is that after a few days the controllers stop working. When I go into the docker container logs, I see in all of them that there are Too Many Open Files. I have tried changing limits.conf sysctl max files for processes and user. After all of that, the issue still shows up.
One interesting thing is that this was not happening until I had to reboot all of the controllers. I rebooted them because I needed to increase the amount of ram that they have after they died swapping. My first thought was that kolla-ansible is setting a configuration after running deploy, but I can't seem to find any point in the repo when kolla-ansible is changing ulimits or other.
Any theories what could cause this? Would it be related to increasing ram? Should I run reconfigure/deploy on each controller? I've tried looking in kolla-ansible's docs and forums and couldn't see where anyone else was having this issue.
Update this hasn't been fixed yet:
I submitted a bug report, https://bugs.launchpad.net/kolla-ansible/+bug/1901898
I don't know your used versions of Kolla-Ansible and your Linux, but your problem seems really related to this one:
On Ubuntu 16.04, please uninstall lxd and lxc packages. (An issue exists with cgroup mounts, mounts exponentially increasing when restarting container) (source: docs.openstack.org/kolla-ansible/4.0.0/quickstart.html)
I had this problem with the exponentially growing number of mount-pointers after the restart of my docker-containers too. My single-node test-deployment had become very slow based on this problem, but I can't remember at the moment, that I would had the same error with too many open files.
You can delete the packages with apt-get remove lxc-common lxcfs lxd lxd-client. I had done this fix together with a complete reinstallation of the kolla-ansible installation, so I don't know, if this also helps with an already existing installation. You should also use docker-ce instead of the docker from the apt-repos.
This was fixed with a workaround in bug https://bugs.launchpad.net/keystonemiddleware/+bug/1883659 problem was neutron server was keeping memcached connections open and not closing them until the memcached container reached too many files open. There is a work around mentioned in the bug link.
My goal is to follow "Deploying a Meteor app with Nginx from scratch" tutorial available here
After installing Meteor, Node, Forever and Git, do the npm install, I try to "run meteor" to see if it works.
After downloading meteor-tools, the process begins to extract meteor-tools... looks like it is hanging for a couple minutes and then stops without any warning.
So my guess is that something causes the extraction to quit, but i don't know what exactly.
Yes, Meteor likes plenty of RAM. I would recommend using Phusion Passenger with nginx for Meteor, it's very easy to set up, and their tutorials/getting started is very good:
https://www.phusionpassenger.com/library/install/nginx/install/oss/
I haven't found the exact reason. However, I got it working. I was using a DigitalOcean server (512Mb/20G). I tried with a big server (16G/160G) and it works.
So I guess my server Ram OR Disk capacity was too small.
Edit:
setting up smaller configuration, i noticed that the minimum for Meteor to work is: 2Gb of RAM and 40Gb Disk.
I am using R 3.3.0 on Rstudio on Ubuntu 14.04 and have installed package Affy successfully.
However, when I set the directory where CEL files are, (using setwd()) and give the command cel1 <- ReadAffy(), there is no output. I don't even go the the next line with >. It simply does not show any output.
Also, Ctrl+C and Esc are also not stopping the process. Usually Esc works for stopping the process on my system. Here is the screenshot:
Also, when I try to quit the session, it takes too long to respond. What is causing this problem and how do I solve it?
EDIT:
I only have 3 CEL files in the folder.
EDIT #2:
I also applied it for single file, but takes again too much time. System monitor screenshot:
It is taking a lot of CPU and a lot of memory(in GB). What is causing the problem? I am using a simple command ReadAffy(filenames = "N54.CEL"). Why is that causing the problem? Any suggestion at all will be helpful. Kind of desperate here.
Turns out there was some problem with the file itself. I got the file from a different source, and it worked fine.
Some of you may have already read my unanswerd question "Node Gallery won't show images with Plupload" AND this query is a follow on, because I think if I solve this issue, I will have found the solution to my previous one, as I missed out a step!
I am trying to patch the Plupload module with the plupload_url.patch, on my laptop running a 64 bit version of Windows 7, but every method I try fails; I think it says the file format isn't supported! So far I have tried GnuWin32 (but I think the clues in the name there), and also the JDiff Plugin for jEdit! So, has anyone been in this situation, or do of a working solution? Any advice would be greatly appreciated!
I do have a VirtualBox installation of Ubuntu if there are no other alternitives, but I'd prefer not to use that because transfering files from the Guest OS is a pain in the ass!
If I understand correctly, the problem is that you can't apply the patch and want to know how to do so.
Here's an explanation of path files which may help: http://drupal.org/node/367392
Also see if http://drupal.org/node/14231#comment-22770 and http://drupal.org/node/100527#comment-176252 helps.
Today I stopped/started my GlassfishV3 instance and now I cannot access the addmin console located at http://servername:4848/. The screen says: "The admin console is loading..." This is going on forever now.
I have tried as follows:
I have tried adding the following entry to my domain.xml located at /glassfishv3/glassfish/domains/domain1/config as suggested in another Stack Overflow Q&A but after restarting the server still no luck.
<java-options>-Dcom.sun.enterprise.tools.admingui.NO_NETWORK=true</java-options>
I have also installed glassfishv3 on my local machine and cannot recreate the problem.I can go to http://localhost:4848 without any problem.
I have also looked at the server.log and jvm.log files located under the /glassfishv3/glassfish/domains/domain1/logs and nothing there that shed some light.
Any help would be very much appreciated
I had similar symptoms, and I tried some of what Dario had suggested as well, but it didn't work. It could be that I had a unique configuration for my dev env: I'm running Glassfish 3.1 on a VirtualBox Ubuntu 11.04 64-bit guest on a Windows 7 64-bit host. Quite by accident, I discovered an additional symptom: if I turned off the network on the Ubuntu guest, the console would load successfully on a localhost browser instance. That is, on the Ubuntu guest with the network off, I could successfully navigate to http://localhost:4848 and show the Glassfish admin console as expected. However, if the Ubuntu guest's network was on, I had the exact behavior suggested by the original poster: http://localhost:4848 would just sit forever on the inial loading page.
To make a long story short, I found that adding the following argument to the JVM options for server-config fixed the problem:
-Djava.net.preferIPv4Stack=true
When I made that change and restarted the Glassfish server, everything worked.
(Note that I also had in place some of the other settings recommended above, i.e., NO_NETWORK=true, and I'd adjusted the JVM memory footprint and set it to -server instead of -client. It could be that these settings are required as well, though they weren't sufficient on their own in my case.)
I was having this exact same problem. I could deploy in run mode, but it would hang forever in Debug mode. IntelliJ was hanging on the breakpoints. I muted the breakpoints, and glassfish3 worked good as new. I didn't have to change any domain.xml settings. Check your breakpoints!
I found a solution to my problem. Setting the java-option to NO_NETWORK to true did not work so I upgraded from 3.0.1 to 3.1 and it got fixed. Not immediately though, I had to stop/start the Glassfish server a couple of times before I got into the admin console without any really long delays.
Solution
The solution was to upgrade from the command line using the pkg utility.
You can find the steps in this link:
http://download.oracle.com/docs/cd/E18930_01/html/821-2437/gkthu.html#gktjf
Or do as follows:
Go to as-install-parent/bin
./pkg image-update
as-install-parent/glassfish/bin/asadmin start-domain --upgrade domain-name
as-install-parent/glassfish/bin/asadmin start-domain domain-name
UPDATE
I had peformance issues again and I found this other solution in Joshi's tech blog:
http://joshitech.blogspot.com/2009/09/glassfish-application-server.html
Basically add the following jvm options in the domain.xml. It should increase Glassfish boot up and deployment performance:
<jvm-options>-server</jvm-options>
<jvm-options>-Xms3000m</jvm-options>
<jvm-options>-Xmx3000m</jvm-options>
<jvm-options>-XX:MaxPermSize=192m</jvm-options>
<jvm-options>-XX:NewRatio=2</jvm-options>
<jvm-options>-XX:+AggressiveHeap</jvm-options>
<jvm-options>-XX:+AggressiveOpts</jvm-options>
<jvm-options>-XX:+UseParallelGC</jvm-options>
<jvm-options>-XX:+UseParallelOldGC</jvm-options>
<jvm-options>-XX:ParallelGCThreads=5</jvm-options>
I don't know if you are referencing this answer, but there is a second step described (disabling update module).
Two more ideas:
Check if the NO_NETWORK=true option really works (there should be no ads in GF admin console)
Watch the server.log (glassfish-install-dir/glassfis/domains/domain1/logs) during startup and look for the last log entry before the delay occurs. This could be a hint for the source of the delay.
Beware of blindly following Dario's example unless you've lots more RAM than most do.
-Xms3000m gives 3gb to Glassfish. Do YOU have that much spare RAM?
I tried this on my 4gb Mac with 1gb for Glassfish. Made no discernable difference at all...performance still sux.