What do you do if it has remote repo gone over 4GB?
My local Repo is now 1.75 GB only after running
git gc --prune=now
How do I refresh the Remote, to be the same size of the local and thus making it under 4GB?
Related
I’m using Jenkins master slave with Gerrit plugin. Multibranch scanning is taking very long (around 24mins) for a repo with around 80 remote branches and 750Mb in size. Jenkins master is running on version 2.319.3 with 8 vCPUs and 32GB memory. However, the resource usage is very low despite the scanning takes very long. I’ve also checked the disk IOPS and network both looks good. Manually execution of git fetch command in master takes only 45 seconds. Any reasons for the long branch indexing?
I am running builds on openshift jenkins and due to swap memory issue jenkins is running very slow and as result builds are taking longer time or failing. Is there a possible way to increase the efficiency of jenkins or improving the speed of jenkins??
Background
Can anyone provide some insight into exactly what the responsibilities of a Jenkins master is with regards to capacity planning.
I have a single master and slave set up currently where the master is a much less powerful EC2 t2.micro but the slave is a t2.medium.
Every now and then the master dies and there are errors relating to out of memory errors and unable to allocate memory on checking out a project. Jenkins has been configured with -Xmx768m.
I have verified that the build is tied to the slave node and not the master. The master has 0 executors configured and the job shows as running on the slave (1 executor).
Example Error
This is one such example
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from https://github.com/xyz.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:825)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1092)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1123)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:120)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:262)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
Caused by: hudson.plugins.git.GitException: Command "git fetch --no-tags --progress https://github.com/xyz.git +refs/pull/16/head:refs/remotes/origin/PR-16 +refs/heads/develop:refs/remotes/origin/develop" returned status code 128:
stdout:
stderr: error: cannot fork() for fetch-pack: Cannot allocate memory
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1990)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1709)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:400)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:823)
... 8 more
My Question
What is the role of the master in this setup from a resource utilisation perspective? I'd have assumed it would be the slave that is checking out the project and building (not the mater). - hence why I allocate much more resource to the slave in terms of memory, CPU, disk capacity and IOPS.
Aside from centralised plugin configuration I didn't expect the master to play much of a role beyond starting an agent on the slaves via SSH (not something I expected to be intensive work from a mem/CPU point of view).
In the short term I plan to upgrade the master to a more powerful EC2 instance type, however - it'd be good to understand more about what the master really requires to ensure I'm planning capacity properly and not needlessly provisioning far too much.
If you're getting this error in the build log, and you've scripted your build to run on the slaves, either by requesting a node tag or by reducing the number of the executors on the master to 0, then the checkout will happen in the build agent.
If so, then what's running out of memory is not your master, but your slave.
I would try increasing the heap size for the slave.jar. How you do this will depend on how you're firing up the slaves.
From this bit in the Jenkins documentation you'll see it reads:
The JVM launch parameters of these Windows services are controlled by an XML file jenkins.xml and jenkins-slave.xml respectively. These files can be found in $JENKINS_HOME and in the slave root directory respectively, after you've install them as Windows services. The file format should be self-explanatory. Tweak the arguments for example to give JVM a bigger memory.
But if you're firing them up from the command line using java -jar slave.jar then here's where you should make use of the Xmx parameter. Maybe the box where you're running the agent does have enough memory available, but the Jenkins agent is just not using it.
Also, here's a really interesting page in the Jenkins wiki covering how to size both masters and slaves.
I have two computers and want to use only one for deployment.
I regularly do push to my private git repo on another computer and on the current computer I do both push to git repo and deploy to heroku.
If I made changes on another computer (such as adding new files) and push to git repo, then pull these into yet another computer then push back to git repo then push to heroku, would my changes on the first computer (the new file for example) deploy correctly to heroku?
I currently have a remote to an EC2 instance set up on on my local git repo. The push works.
git push remote_name master
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (12/12), 896 bytes | 0 bytes/s, done.
Total 12 (delta 6), reused 0 (delta 0)
To user_name#dns:eko_web.git
4342c41..7bbc7db master -> master
When I ssh into the remote EC2 I can find the very first push I made copied over my app to var/app/current/ but no further updates. When I look in my bare git repo I find my most recent pushes when I do git show HEAD:<some_file>. When I manually edit the view in var/app/current the change isn't reflected in my website; the same initial push is all I see. I have a hook set-up in the post-receive of the bare git repo that is the following:
#!bin/sh
GIT_WORK_TREE=/var/app/current git checkout -f
As a broad overview, I used the following tutorials to get me this far. http://myrailslearnings.wordpress.com/2013/02/19/getting-ec2-to-use-git-for-rails-app/ http://www.lovholm.net/2013/06/26/push-your-code-onto-your-ec2-instance-with-git/
Thanks for any thoughts on this!
Edit:
Per Rico's suggestion, I started a new instance that hadn't been initialized with Beanstalk. I now have a git repo on the instance that (when updated manually) reflects changes on the server. But I'm still having problems pushing remotely to that location; it shows a successful push but then the files are there but not committed. If I commit them manually and then restart the server the website is updated.
There are many ways you can do the deployment. Deploying by pushing directly to a non-bare git repo can be done but it's not that common. (Like http://www.lovholm.net/2013/06/26/push-your-code-onto-your-ec2-instance-with-git/ describes) There are things that you have to watch for. For example you cannot push to a remote repository branch if that branch happens to be checked out.
From the looks of it you were deploying through Elastic Beanstalk initially or something because /var/app/current is the default location where it deploys Rails apps (when you do a git aws.push) Keep in mind that in a regular Elastic Beanstalk deployment /var/app/current doesn't hold a git repo. It's just a copy of your code (The git repo is saved somewhere else, I believe in S3)
The most common way of deploying from git is to have your git repo in github, bitbucket or a git repository in the cloud. Let's say you use github. At deploy time you would push to the github repository and then the new code gets deployed by cloning or pulling from the github repository into your cloud server. Capistrano is one of the tools that automates this process.
Another way of deploying is pushing to a bare git repository in the same say EC2 server where you are deploying and then pull/clone from that bare repository into another non-bare repository in the same server.
In your case you can also try switching your remote repository to non-bare if you want to see the code there. Easiest way I guess is deleting your bare repository and then cloning the original as a non-bare repository and sticking it where you want to deploy your code.