Sorry if this question is a bit vague. I don't know the right technical terms.
Basically in my research group we use a shared windows machine with a lot of RAM to run models, using remote desktop to access it from our own computers.
It would be great if we could build a queue so that we get the most use out of the machine, especially if we could then rearrange the order once it is up and running. Often someone will want to run say 50 runs of a 2 hour model, and someone else will just want to run once and check the results immediately, so they should get priority, but it's a pain stopping and starting large sets of runs.
We run models via command line, any ideas?
You could store the total time each user has spent on the computer and it would also be a good feature to let the users estimate the time they intend to use the computer. The queue could be built based on these data and if it is possible, when the estimated time is left 110%, then automatically kick out the user and allow the next to use the computer. I think you should implement a very basic system without too much effort. When all of you see it, you will have ideas about the optimal direction where the project should be headed.
Related
Frequently last few days onwards our GitLab(CE) running slowly. We have a hook for the CI with Jenkins. We had installed the GitLab by OmniAuth. I don't have any more ideas regarding this because we didn`t do anything new in our instances.
We are the newbie to GitLab environment. We are working in the GitLab since December 2016 and also we never faced this kind of issue before. I hope that I will fix this problem with you people. Kindly help me to fix the issue.
Follow the below image for our Gitlab details.
How could I overcome from this issue?
These are just some as-is suggestions offered without warranty, but they may help guide you to solving the problem.
Occam's Razor
You mentioned that these issues appear to have just started most recently. This means that the VERY FIRST place to look is what may have changed around the time that these issues occurred. If you have change control for your infrastructure, start there. Make absolutely sure nobody has changed anything around the time these issues started happening. Check your logs for any warnings that may have started showing up. If your OS has a security log or logs configuration changes, check those. If you don't have good visibility/audit-ability into your environment, this may be hard, but if you can identify something that changed around the same time as these issues started occurring, that is most often going to be your problem.
Specificity
It may be helpful for you to describe what you mean by it getting slow. Is it a specific operation that is slow? Or is it all activity? If it's something specific, like triggering a Jenkins job, then you can start to isolate your search there.
It can also help to run top on your server to get a picture of what might be causing the issues. There might be a specific process running on the machine that is dominating everything else and eating all of the resources.
Hardware
First thing I would check is to make sure your hardware configuration matches the 'Hardware requirements' guidelines on gitlab's website:
https://docs.gitlab.com/ce/install/requirements.html#requirements
Based on what you've posted, the CPU and memory on your system seem adequate for several thousand users, so I'm going to assume this isn't a problem, but in case you do have thousands of users, I will add some brief information on this. Your disk configuration (other than size) is not presented in the information above, so we don't know if that is sufficient or not.
I would recommend running vmstat on the server (since it's GitLab, I am assuming this is running on Linux, since they do not recommend Windows installations) to get some basic information about what is going on. The vmstat command will give you several columns of information. To the very left there should be a column 'r'. This is the 'run queue', or the number of processes that are waiting to be run on a CPU. If the value in that column is large compared to the number of cores the system has, you probably have a CPU bottleneck. The next column, 'b', is processes that are blocked. If this is large, you probably don't have a CPU bottleneck. To the right, there are CPU columns: us, sy, id, or something along these lines. These columns are a breakdown of where the CPU is spending its time, either in the application code (us), in the OS code (sy), or waiting (id). High percentage numbers in us generally indicate that you either are running healthily or have a CPU bottleneck. High percentage numbers in sy are usually going to indicate some kind of contention, possibly a configuration issue like having too many worker threads configured for the number of CPUs you have. A high percentage number in id usually indicates that the system either isn't doing much, or can't do much because it's waiting on something like disk or an external database.
So if the 'b' and/or 'id' columns in your vmstat output have high numbers, we may want to consider the possibility of there being an I/O bottleneck. Here are a couple introductory articles on evaluating Linux IO for bottlenecks that might help you determine if this is the case:
https://bartsjerps.wordpress.com/2011/03/04/io-bottleneck-linux/
http://www.linux-mag.com/id/2001/
These articles should get you pointed in the right direction to help you decide if your disks aren't fast enough.
One thing to note, if you're seeing what appears to be a CPU bottleneck (high r values, high us values), make sure that situation makes sense for the number of users you have. The CPU bottleneck may be caused a virtualization issue, or some OS issue causing the CPU to perform poorly, not just by the CPU hardware itself being insufficient.
Topology
One thing mentioned in the gitlab requirements I linked to above is that it is not recommended to run GitLab runner on the same box as GitLab itself. This is something I would say is true for any CI software working with GitLab. If you're running GitLab Runner or Jenkins on the same box as GitLab itself, you should consider moving those to their own hardware.
If you have thousands of users, you may wish to get in contact with GitLab themselves and have consulting on how to get an enterprise-grade cluster stood up and what that looks like. There are people who are experts in the specific hardware configurations that make sense for a very large GitLab installation, and I am not one of them. However, if you don't have a large number of users, the hardware you have is probably not the issue.
Software
If you're running things like vmstat and iostat and you're not finding any specific hardware bottleneck, there may be a configuration issue. Make sure you have a good number of Unicorn Workers configured, so that the box can properly utilize your hardware.
External bottlenecks
Make sure things like network speed on the server are sufficient for its needs. Make sure users trying to reach the server aren't being bottlenecked by a misconfigured network. If you're using OmniAuth, make sure the provider is performing correctly. For example, if you're using some external authentication, and that isn't scaling/performing well, you'll get bad performance in GitLab as well. These are especially important to look at if you're not seeing much hardware utilization using the methods above.
Two aspects which can help accelerate GitLab are, in the latest April 2020 12.10 version:
the application server which switches back Puma
the caching of Git info/refs
The last point is:
When fetching changes from a Git repository, the server advertises a list of all the branches and tags in the repository, known as refs.
In some instances, we have observed up to 75% of all requests to the GitLab web server are requests for the refs.
In the best case, when all the refs are packed, this is an inexpensive operation.
However, when there are unpacked refs, Git must iterate over the unpacked refs. This causes additional disk I/O, which is slow when using high latency storage like NFS.
In GitLab 12.10, info/refs are cached to improve the performance of ref advertisement and decrease the pressure on Gitaly in situations where refs are fetched very frequently.
In testing this feature on GitLab.com, we observed read operations outnumber write operations 10 to 1, and saw median latency decrease by 70%.
For GitLab instances using NFS for Git storage, we expect even greater improvements.
See Documentation and Issue.
I was wondering if it was even possible with RUBY to watch other applications and if a certain application is below a memory threshold it kills it and starts it again.
Operating System would be Windows 7+
Things I need to be able to do:
Monitor Memory
Determine between different processes
Kill Processes
Start new process (bat script or powershell)
Start monitoring again
The watched application running would run high memory when it is working and that is good. If it goes below 1gb I want this application to kill it. Of course when it restarts it would give a grace period for it to load the RAM.
I was going to use the Shoes gui framework to make something nice to wrap around it. It would be theoretically nice to have some sort of auto detection if the application is running.
If this is possible, but requires Gem you think may help I would like to hear about them.
I found Usagewatch Gem seems to be headed the right way, but from a glance at the documentation it is general and I need to be specific about which process I am watching.
If this question is not appropriate here please let me know via a comment and I will remove it and/or move it to a proper place for this type of question to be asked.
I appreciate your time and effort into helping me with this endeavor.
Thank You
I would suggest using the win32 gem. Than start by looking through the Win32 Api documentation. This will give you the most flexible solution and will give you the whole system programming power for Windows. My advice is to make some wrapper functions about the things connected with Windows you need and use them that way, so if you find a more appriete solution you can switch to it easily.
I am trying to set up an automatic uninstaller for a program. basically I want the program to uninstall after a certain time has passed (lets say 1 year).
Is there any way I could do this? It would basically be a trial version of the software.
Sorry for not being specific about this but i just want some options on how I could do this easily.
Thank You in advance for your responses and sorry for my bad English.
I have never seen such a design. I suppose you could use a scheduled Windows task, but why do this? You can just have the application expire after a year and offer a button on launch to kick off the uninstaller? It can launch the uninstall asynchronously and shut down the application right away.
I have also never seen such a design, likely because it fails to consider several issues, namely how do you keep users from:
reinstalling it?
installing it on another machine, or on a VM with snapshots?
restoring a hard drive backup over it?
killing the uninstallation?
Software licensing is hard to get right. I would recommend using a third-party licensing package that offers trial licensing. I would avoid trying to roll your own solution, as it will likely take you a lot of time to develop and be ineffective nonetheless. Picking the right product for this depends on first answering some questions, though:
How a. skilled and how b. determined will the adversaries be who are costing you the most amount of financial loss? That is determined by:
How much money will you lose if you don't protect it? This should determine the next question, which is:
What is your budget for software protection? It should be less than the amount you would lose without it. This should include the next question, which is:
How many hours do you want to invest to get this working?
It sounds to me like you want an automated wrapper that will work with precompiled applications / installers, as opposed to using an SDK you must integrate into your code.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I would like to add licensing system to application. For example: user buys license for 1 month and after that program expires (Kinda Anti-Virus style?).
Problem is that application is supposed to run in systems which may or may not be connected to internet, so how to protect from date-time changes?
Storing app startup and close times in encrypted file won't work as date can be changed (with program uptime of 8 hours per day, would be possible to extend license to almost 300% in ideal case - change time to app close time + 1 second before launching program).
Another question - is there any way to protect from software like http://en.wikipedia.org/wiki/Deep_Freeze_(software)? (maybe scan drivers?)
EDIT:
I'm currently using smart card to store licensing information and will use code virtualizer on critical functions (I know about making breakpoints on API calls and inspecting passed data - don't need to hide that data, just to ensure things go as planned)
Yes, it would be possible to extend the license by up to 300% but at great effort to the user. Frankly if someone is going to spend every day of a month resetting their time to one second after they quit your program before starting it again to use it longer, there is nothing you are going to do about it, and the time you take to stop them will cost you more than they ever will.
Step 1: Create trial_tracker entry in an encrypted format in a windows registry and in file.
Step 2: Assign app install timestamp ( yyyy-mm-dd-hh-mm-ss ) to trial_tracker
Whenever app starts, check if current system timestamp is greater than trial_tracker and less then expected expiry date
If yes, update trial_tracker to current system timestamp and continue.
If no, trial_tracker has been tampered or trial time expired. Ask user to purchase full version or exit.
Note: User can get away with this by deleting windows registry entry and encrypted file.( if he is able to find them ).
In such case, further checks can be added. For example create secondary windows registry entry which checks for existence of primary registry and encrypted file.
Along with these, additional remote checks can be applied which depends on internet connection ( optional )
Reputable game development manager stated once in a conference that it's impossible to protect software for longer than a month even with internet connection - if your software is popular :-) So you can just write software that no one wants and it will be as safe as you want :-)))
If on the other side you write reasonably popular software then you couldn't care less if a small percentage of paying customers snitch some extra time - they'll renew a week latter anyway. If you really want to do short time licensing you have to put internet as a pre-requisite. It's still going to be cracked in a month if it's good for something :-) but paying customers will by and large remain paying customers with reasonably light enforcement.
If however you piss people off by doing intrusive and scary things then you'll loose paying customers and create much bigger motivation for ppl to crack it.
Create a windows service that gets installed with your app, but is auto-start. Keep track of elapsed time and offsets there. Provide an API for your app to talk to the service to query usage/elapsed time.
I assume the software phones home at least once to let you know the license key has been bought / installed / extended?
After the time has ran out since they bought the license key and they haven't purchased another you could contact them and ask them how they are getting on and to let them know they need to renew. If they do choose to abuse your system a simple call to chat about it may be enough to get them to stop.
Maybe you could combine the use of the date/time with the tick count? Then if you see a date/time with an incompatible tick count, you could flag that as a violation. This would change your worst case scenario to require them to restart the machine whenever they want to manipulate the clock to abuse your license.
From your program you create a log of time when the app is launched and exited.The log is encrypted and prevent the common user to trick its content.
With this log, you can see if time elapsed normally that is time goes to the future. If not then something fishy is occurring on this system. In this case display a dialog box with a phone number where they can call you.
You could also ensure via a data file that the program can run for one month only after that as the said data file don't contain the data to work for the following month, this requires an update.
The idea is that time is flowing linearly to the future, it can only increase the counter from the launch date and external data is required for the program to run in the future so you've created a dependency relationship on updates. This last strategy is what Microsoft and co used and they call it security updates / patches...
You shall decrease the time elapsed between checks. Instead of checking only at application startup and application shutdown, you shall check every 5, 10 or 15 minutes using a timer or a background thread. In this way the user cannot change time (because the software will stops in few minutes).
However, I'd prefer to pay a software that I need instead of not having the correct date/time on my machine.
Create a Windows driver that starts on boot, grabs the system date-time, and runs until shutdown, tracking the time independently from Windows [ sleep(1000); ++time; ].
When your application starts up, check that the service is running, and check the date-time! Compare it to the date-time you were installed on, and you can figure out if you've expired or not.
Note: If any application did this, I wouldn't install it in the first place. If I WAS tasked with cracking it, it would be trivial. There is no way to prevent reverse engineering. NONE. It WILL get cracked no matter what. And when it does, you're going to regret putting any time into this.
Enable Privilege Use logging (in the installation process) and then check for a time changed event in Windows' event log, as explained here:
http://www.stevebunting.org/udpd4n6/forensics/timechange.htm
You can then deduct the time difference from the license (rather than void the license, since some system clock changes are legitimate).
NOTE: This will not protect from changes of the system clock when changed from the BIOS.
You are putting too much effort in the protection itself.
Instead your trial software should contains annoying limitations that will not prevent your users to evaluate it but will certainly prevent them from using it for business.
Maybe you could offer this software as a service if you are so worried about enforcing the licence?
One way to do is to store the current time and date of software download in an encrypted file that should be used along with the package.
Another way is to store file in the user computer and keep checking with your hard coded date in the software with that file.
I have a complex legacy data migration problem. MS Access data going into MySQL. I'm using a Rake task. There's a lot of data and it requires a lot of transforming and examining. The Rake task is hundreds of lines across about 12 files. The whole thing takes about two hours to run. It has to run on Windows (I'm using XP VMware VM hosted on an OS X Leopard system) because the Ruby libraries that can talk to MS Access only work on Windows.
I'm finding that sometimes, not every time, I'll start the task and come back later and it will be stalled. No error message. I put numerous print statements in it so you should see lots of reporting going by, but there's just the last thing it did just sitting there. "11% done" or whatever.
I hit Ctrl-C to and instead of going back to the command prompt, the task starts up again where it left off, reported output starts going by again.
I'm sorry for the abstract question, but I'm hoping someone might have an idea or notion of what's happening. Maybe suggestions for troubleshooting.
Well, if the access side seems to be freezing, consider shoving the data into MySql, and see if that eliminates this problem. In other words, the data has to go over eventually, you might as move the data into that system from the get go. There is a number of utilities around that allow you to move the data into MySql (or just export the access data to CSV files).
So, you not doing data transformations during that transfer of data while you move it into MySql (so, it not a labor nor programming cost of time here…just transfer the data).
Once you have the data in MySql, then your code is doing the migration (transformation) of data from one MySql database (or table) to another. And, you out of a VM environment and running things in a native environment. (faster performance, likely more stable).
So, I would vote to get your data over into MySql..then you down to a single platform.
The less systems involved, the less chance of problems.