I have found many posts that indicate that these files will be cleaned up after one week (my temp/tmp has files over one month old). Some say restarting sonarqube will clean these out (does not work for me to restart the application due to continuous integration). Some posts claim that this is fixed in the next sonar and sonarqube release.
How do I know (definitively) when it is safe to delete the content from temp/tmp directory without impacting the analyses? Currently there is 31 GB of data and I badly need to reclaim that space!
any pointers are welcome!
Indeed, this question looks actually like a duplicate of SonarQube Temp Disk Space and this issue is a known one. And it's been fixed in SonarQube 5.1.2.
See https://jira.sonarsource.com/browse/SONAR-6700 for details.
If you can't upgrade, then you can just remove old temporary files by yourself in the meantime. Something like :
find $SONARQUBE_TMP_DIR -type f -mtime +7 -exec rm -f "{}" \;
should do the trick (the +7 is to say MORE (+) than 7 days old for last modification, mtime is modification time, adapt if you want more or less).
Warning: do NOT put less that +7. I did it some weeks ago and it crashed our instance. My guess here is that since SonarQube is supposed to automatically clean up things older than 7 days, it might still be using files old less than 7 days... Hence, leave them alone ;-).
Best solution I found is to restart sonarqube. It took some time to remove the tmp files, but restarting it definitely did the trick.
Related
My question is the same as the one posed here:
Ignore a folder in search results
I'm using PyCharm rather than IntelliJ-IDEA, but I'm guessing that features common to all JetBrains IDEs should work the same. If the accepted answer actually did what is suggested, it would be just what I'm looking for. But it doesn't work for me. It does something interesting, but not what I want.
I have marked directories I don't want searched as "Excluded". My problem is, files aren't excluded from my search results as suggested. The interesting thing is, matched file in the directories I've marked Excluded ARE HILIGHTED to indicate that they were found in one of those directories. So I know I've got everything set up right. The GUI is showing me which files I can myself ignore by way of hilighting them in the search results window. So if it's going that far, surely there must be an option somewhere to exclude them completely. I've looked and looked. I can't find such an option.
Here's a sample result so that you can see what I'm talking about in terms of the hilighting:
Here, what I want is for the first four files shown here to show up but not the remaining eight. Can anyone tell me how to get Excluded files to not show up at all in a Jetbrains Find in Files result window rather than just hilighting them differently? TIA.
I sent off a tech support request to Jetbrains. They got back to me in less than 24 hours (I've always had great response times from them). Here's what they said:
Your understanding is correct -- the excluded directories should not
appear in the search result. However, if you just marked the directory
as excluded, it may require a project refresh to update the indices.
This is done when you reopen the project.
If the issue is still reproduced after reopening a project, there may
be an issue with indices, so please try File | Invalidate Caches... |
(Check all boxes) Invalidate and Restart.
If that doesn't help as well, please check if the issue is reproduced
in a new empty project with a minimal structure to reproduce the
issue.
I had already tried reloading my project, then restarting PyCharm, and even rebooting my Mac. None of those things helped. I had thought to rebuild the indexes, but I've got a number of large projects and was concerned that I'd keep hitting delays every time I opened one of them if I cleared out all of PyCharm's caches. But that was about all I had left to try, and since Jetbrains told me to try that, I did.
...and...clearing all PyCharm caches fixed the problem! I no longer see any of the files in Excluded directories when using any of the search modes in the "Find In Files" dialog. To be quite sure that the re-indexing fixed this, before clearing the PyCharm caches, I made a point of closing everything, then opening just the one project I was having trouble with, and then doing a straightforward search. I saw files from Excluded dirs that shouldn't have been there. Then I cleared all the PyCharm caches, and quit and restarted PyCharm. Then I did the exact same search I had done just a few minutes earlier (it took about 5 minutes to re-index the project). The results this time were to only show me what I expected/wanted. The files in Excluded directories were gone from the search results.
This may sound strange, but I am having issues with Xcode mixing branches, or at least messing everything up.
I created a new branch (v1.4), then created a new data model and renamed an entity. Had to switch back to previous branch (v1.3) to check something and I get errors at run time on v1.3, it's looking for the new entity name from Branch v1.4 - what the %$^#% is happening. I searched the files, the new entity name is nowhere in v1.3.
I switch branches again to v1.2 and it ran fine. So, switched to V1.3 again - nogo. Switched back to v1.2 and it has the same issue now, runtime error because it can't find the new entity name.
What is happening? Anyone else have this issue?
Any thoughts/suggestions would be greatly appreciated.
OS X 10.11.6
Xcode 7.1.1
==[EDIT]===
I am not real familiar with GIT, just starting to learn. I ran the couple commands as mentioned, get nothing for either git diff commands.
Running git status --ignored I do get multiple files as untracked - still working on understanding why (Separate issue) - couple object files and 2 data models (Was 3, but manually added one to commit.
Also I get 3 ignored files:
.DS_Store
projectName.xcodeproj/project.xcworkspace/xcuserdata/
projectName/.DS_Store
That's as far as I've gotten. Not familiar enough with git to know if these ignored files are the ones I should delete.
Second option - will restoring from time machine fix this? It may be a little extra work for me to recreate v1.4 but probably less time than I've already spent trying to figure out how to fix it.
I do appreciate both comments so far - thank you.
==[SECOND EDIT]==
Thanks again for your comments.
However, do to time and schedule I perform a Time Machine backup before ElpieKay posted the last comment, so I will not be able to test it.
Reverting back did "fix" it as you'd expect, but I did lose several hours of work but life happens. I will keep this for if/when this happens again and try the git clean -df to see it fixes it.
On a side note - while I was switching back and forth between V1.3 and V1.4 trying to figure this out, 2 of the model versions disappeared on v1.4 - i.e. the name turned red in Xcode and when I viewed the contents of the file they were missing. I do not know if this is related or not, but I thought I would mention it. This happened one other time and I thought maybe I did something - I did a time machine restore to fix it last time. Wonder if git clean -df would have fixed it.
I'm having an issue which I'd have thought others might have come accross, but I can't find any posts.
My (small) WiX projects are taking ages (2-4mins each) to build on our build server, but are much quicker on my desktop (a few seconds).
After some poking around I've narrowed it down to McAfee scanning the temporary files created by light (located in the TEMP user environment variable). I don't know why it's taking so long to scan - disabling the AV has got the build time to well under 2 mins, previously it was over 20!
Now my issue is how to exclude these temp files from the AV. I don't want to exclude the TEMP folder for obvious reasons and there doesn't appear to be a way of excluding by file name without creating a big hole in the AV.
So I guess my question is, is there a way of configuring light.exe to use a different path other than TEMP? I tried some command line switches with no luck. Maybe I could add something to the Light.exe.config?
Cheers.
Can you not just disable real time antivirus scanning on your build machines? My argument for doing this would be that your VM should be full scanned and then disabled and that all files making it's way into the build machine are coming from source control and / or file shares that should have already been scanned at various points upstream in the process.
We ran over 100,000 builds a year at my last job and A/V would have killed us.
Otherwise, if you type light.exe -? you'll see there is an environment variable called WIX_TEMP that overrides the temp directory.
I am attempting to perform a stackwalk with Xperf, using a batch file similar to the one listed at Getting the symbols with xperf.
I launch XperfView, confirm the symbol path is correct, and then load the symbols. However, when I attempt to open a summary table on a selected portion (5 seconds or so) of the "CPU Sampling by CPU" graph, the Performance Analyzer hangs (not responding) for a long time (hours).
I left it running last night, and when I came in this morning the Summary Table had finally loaded, containing results as expected... I had thought perhaps it was just performing an initial download to cache the symbols to C:\symbols, but a repeat test this morning has similar problems (hang for 1 hr 15 minutes at this point).
WPT (xperf, xperfview, WPA) doesn't ship with dbghelp.dll and symsrv.dll. That means that, depending on what is in your path you may get:
Fast symbol loading
Symbol loading that takes up to 150x longer
No symbol loading at all.
The solution is to copy a known-good version of these DLLs into the WPT install directory. For more details see this post:
http://randomascii.wordpress.com/2012/10/04/xperf-symbol-loading-pitfalls/
In his post , Bruce Dawson speculates that there is an issue with dbghelp.dll and/or symsrv.dll in WPT as shipped in the current SDK. He suggesting replacing those with the ones either from Visual Studio 2010, or from Debugging Tools for Windows (i.e. WinDbg). Worked for me...
Have you set up symcache something like this
SRV*c:\dev\symbols*http://msdl.microsoft.com/download/symbols
The symcache would cache the symbols locally. I usually have my _NT_SYMBOL_PATH environment variable with the above information.
HTH
we recently performed an upgrade of our whole perforce system to 2009.02
During this exercise, we noticed that the back-up /restore process that was installed here by the Perforce consultant a year ago was not completely working. Basically, the verify command has never worked (scary !).
As we are obliged to revisit our Back-Up/Restore scripts, I was toying with the idea of using the new p4 replicate command. The idea is to use it alongside an rsync of the data files, so that in case of crash we will lose at worst an hour of work (if we execute them every hour).
Does anyone has the experience or an example of back-up/restore scripts using the p4 replicate command of the 2009.02 version ?
Thanks,
Thomas
Your question is almost one year old, but if you are still curious, I implemented exactly what you are talking about. I did it around the time you asked the question, but I didn't know about this site.
rsync'ing along metadata replication works great - we still use it in production.
The replica age varies, but most of the time it is less than several minutes.
--Mike
FWIW, in the latest version 2010.2 the p4 pull command copies the versioned files as well as the metadata, so there's no need for a separate rsync.