I wrote a RoR Rake script which interfaces with a Python ORM over XMLRPC to import thousands of products from one Postgres server to the Python ORM's server (also on Postgres).
The script was running fine. I stepped away from my computer and returned in 5 minutes to see the following error:
rake aborted!
Net::ReadTimeout: Net::ReadTimeout
What might have caused this error?
NOTE: I am writing this question with the intention of providing my own answer so as to help anyone in the future who might encounter this issue.
The error was caused due to my computer going to sleep, or at least the hard drive spinning down and going into low power mode.
I know the cause of the error may seem obvious, but I figure it's worth throwing out there.
I was running macOS Mojave 10.14.
I addressed the error by going to System Preferences/Energy Saver/Power Adapter and checking "Prevent computer from sleeping automatically when the display is off" and unchecking "Put hard disks to sleep when possible" (although I doubt that second one was at all necessary, I did it just in case).
Related
I am running some services with Google Cloud Run. While performance has been satisfactory, there's a recurrent issue with extremely slow startup time, which leads to occasionally dropped requests when new containers can't spin up in time.
Currently, with first gen execution environments and startup CPU boost enabled, Google's dashboard reports around 18 to 50 seconds of startup time. Image is based on ruby:3.0.2, and it runs a Ruby on Rails 6 application. In a development environment, startup (timed from run to container accepting requests) never seems to take more than 5 seconds.
I want to know what tools are available to diagnose this issue, and if there are any obvious pitfalls with my specific case that I might be missing.
I've tried playing around with the service's configuration options, to no avail. The biggest suspect is a startup bash script that handles migrations on the first boot, and asset compiling on development. However, I've tried building with an empty script, and the problem persists. I also think the container images might be too large (around 700Mb), but I haven't gotten around to slimming then down nor found evidence that this is the problem.
I'm on Windows 8.1 and have been trying to get Rails to work on my computer for quite some time now. I followed the guides to install Ruby and Rails and everything correctly, but whenever I try to execute any kind of Rails command through PowerShell, I get an error with one of the gems. I can't run the server command, can't generate, can't run console. Here is the most recent error:
C:/RailsInstaller/Ruby2.1.0/lib/ruby/gems/2.1.0/gems/execjs-2.5.2/lib/execjs/runtimes.rb:48:in 'autodetect': Could not find a Javascript runtime. See https://github.com/rails/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)}
Other times I get errors with native gems follow guides to resolve those, but nothing ends up working.
How do I get Rails to do anything on my Windows machine? Should I just get a Linux vm?
I would recommend using a vm, I've used virtualbox in the past with ubuntu for rails development.
It's not impossible to get things to work in windows, but you'll probably thank yourself later if you move to the vm.
For the specific error you mention see this SO post which suggests adding therubyracer gem.
If you're getting a different error every time then providing an answer with the steps to get it running would be very hard so I'll stick to a general answer.
With persistence (which, don't get me wrong, you've already shown) you can get rails up and running on a Windows machine. You will spend longer getting native gems to work properly and you will have to search harder, and longer, for solutions to some problems.
I have run rails on both windows (admittedly a few years ago now) and on linux and I have found the latter to be much easier to develop on.
So, it's a trade off between the pain of running rails under windows and the pain of running some of your dev environment on a virtual machine. Only you can decide which is the least painful for you.
I have had a Rails 3 app deployed on Elastic Beanstalk for close to 2 years now. For the most part, I haven't had any issues; however, I recently upgraded to one of their new Ruby configurations (64bit Amazon Linux 2014.09 v1.0.9 running Ruby 2.1 (Passenger Standalone)) and I've been fighting an issue for several days where one of more Ruby processes will consume the CPU - to the point where my site becomes unresponsive. I was using a single m3.medium instance, but I've since moved to a m3.large, which only buys me some time to manually log into the EC2 instance and kill the run away process(es). I would say this happens once or twice a day.
The only thing I had an issue with when moving to the new Ruby config was that I had to add the following to my .ebextensions folder so Nokogiri could install (w/bundle install)...
commands:
build_nokogiri:
command: "bundle config build.nokogiri --use-system-libraries"
I don't think this would cause these hanging processes, but I could be wrong. I also don't want to rule out something unrelated to the Elastic Beanstalk upgrade, but I can't thing of any other significant change that would cause this problem. I realize this isn't a whole lot of information, but has anyone experienced anything similar to this? Anyone have suggestions for tracing these processes to their root cause?
Thanks in advance!
Since you upgraded your beanstalk configuration, I guess you also upgraded Ruby/Rails version. This bumped up all gem versions. The performance issue probably originate from one of these changes (and not the Hardware change).
So this brings us into the domain of RoR performance troubleshooting:
1. Check the beanstalk logs for errors. If you're lucky you'll find a configuration issue this way. give it an hour.
2. Assuming all well there, try to setup the exact same version on your localhost (passenger + ruby 2.1 + gems version). If you're lucky, you will witness the same slowness and be able to debug.
3. If you'd like to shoot straight for production debugging, I suggest you'd install newrelic (or any other application monitoring tool) and then drill into the details of the slowness in their dashboard. I found it extremely useful.
I was able to resolve my run away Ruby process issue by SSHing into my EC2 instance and installing/running gdb. Here's a link - http://isotope11.com/blog/getting-a-ruby-backtrace-from-gnu-debugger with the steps I followed. I did have to sudo yum install gdb before.
gdb uncovered an infinite loop in a section of my code that was looping through days in a date range.
I upgraded to Lion few weeks ago, and it completely screwed by Ruby on Rails environment. I have installing RVM, different ruby versions and can't seem to find a solution for it... I think it was one of the worst decisions I could do upgrading to Lion. It only brought problems to me.
Anyway, I have realised that rendering a page of my application (which works perfectly well on deployed server and locally too in other machines) increases the ruby process memory in 20-30mb which is kind of crazy. So you can imagine that after a while, my ruby process reaches 2gb of memory in use and my computer is not usable anymore.
I have seen many people with problems upgrading to Lion but I have not been able to find a solution for my case.
Any had the same problem? Any ideas how could I try to solve this issue?
Thanks
You could use the memprof gem (No longer maintained and doesn't work for Ruby above version 1.8.7) and memprof.com (Broken Link) to get to the bottom of the issue.
Also you could experiment with using Passenger, Unicorn or Thin instead of the default Webrick to see if that gives you different behaviour.
I do not know how you might fix the memory leak, but can propose one way to contain it and further troubleshoot it.
If you are willing to learn Docker, you can contain your development environment inside a Docker container, all while accessing the code on your local machine, just like a shared folder in Vagrant.
When you run the Docker container that runs, you can specify a limit on the amount of memory that container can use. Your rails server process might crash and stop the container, but at least you won't have to restart your machine.
Maybe that will give you more leeway for troubleshooting the problem in greater depth.
Docker Run Reference, see the section "Runtime constraints on CPU and memory".
I'm having ruby instances from mod_rails go "rogue" -- these processes are no longer listed in passenger-status and utilize 100% cpu.
Other than installing god/monit to kill the instance, can anyone give me some advice on how to prevent this? I haven't been able to find anything in the logs that helps.
If you're using Linux, you can install the "strace" utility to see what the Ruby process is doing that's consuming all the CPU. That will give you a good low-level view. It should be available in your package manager. Then you can:
$ sudo strace -p 22710
Process 22710 attached - interrupt to quit
...lots of stuff...
(press Ctrl+C)
Then, if you want to stop the process in the middle and dump a stack trace, you can follow the guide on using GDB in Ruby at http://eigenclass.org/hiki.rb?ruby+live+process+introspection, specifically doing:
gdb --pid=(ruby process)
session-ruby
stdout_redirect
(in other terminal) tail -f /tmp/ruby_debug.(pid)
eval "caller"
You can also use the ruby-debug Gem to remotely connect to debug sockets you open up, described in http://duckpunching.com/passenger-mod_rails-for-development-now-with-debugger
There also seems to be a project on Github concerned with debugging Passenger instances that looks interesting, but the documentation is lacking:
http://github.com/ddollar/socket-debugger/tree/master
I had a ruby process related to Phusion Passenger, which consumed lots of CPU, even though it should have been idle.
The problem went away after I ran
date -s "`date`"
as suggested in this thread. (That was on Debian Squeeze)
Apparently, the problem was related to a leap second, and could affect many other applications like MySQL, Java, etc. More info in this thread on lklm.
We saw something similar to this with very long running SQL queries.
MySQL would kill the queries because they exceeded the long running limit and the thread never realized that the query was dead.
You may want to check the database logs.
This is a recurring issue with passenger. I've seen this problem many times helping people that ran ruby on rails with passenger. I don't have a fix but you might want to try this http://www.modrails.com/documentation/Users%20guide%20Apache.html#debugging_frozen