I am running some experiments with memcached on Linux (x86-64). I am generating queries to the memcached server using memslap utility. I notice that memcached spends most of time is spent on system (i.e, OS functions). I was wondering if anybody has some insights about which functionality of OS is used heavily by memcached and thus spends most of its time on it.
Thanks
Arka
Memcached only major OS function, outside of daemon process, is related to the libevent. I believe memcached & libmemcached is compiled with OS's shared libevent library, and that time will be generalized as an OS function.
Related
I'm using a program that is calculating things as it receives information and I need it to be running on multiple virtual machines on my PC at the same time.
Now before I was going to set this up, I was wondering which operating system would be ideal to be running on the virtual machines to run as many of them as possible on restricted ressources? The only requirement is that my program is not able to run on Linux.
I was thinking of going back to Windows XP on each virtual machine, assuming the newer operating systems are taking too much ressources for themselves, but that's just a guess.
Hope someone has more knowledge than me about this and can help me out.
Thank you!
If you are NEVER going to take these VMs online XP is a better choice. Windows 8.1 (as well as 10) is a recent design and hence is designed for high powered modern hardware, XP was designed long ago for old slower hardware. Running an older OS on newer hardware will allow it to compartively quick, certainly much faster than a new OS on old hardware. Another matter is what programs you will run, if it is old programs they will be compatible with XP, if it is new ones there is a chance XP will not be able to run them. If you are going to take these VMs online then XP is a bad idea, wonderful an operating system as it was it is now becoming insecure due microsoft stopping producing updates to patch holes in it, And do not forget also that Microsoft wouldn't support XP anymore (http://windows.microsoft.com/en-us/windows/end-support-help), so you should go back to the drawing table and fix your priorities and needs and then decide , cheers !
If you cannot run *NIX / BSD Systems you can use WFL windows xp for legacy computers it works on 128 mb RAM
Update: i386 old systems.
What are the optimal performance tuning settings to put in my sts.ini file to ensure STS runs well on my Mac?
I am looking to optimize two machines. One is a MacBook Pro with 16GB ram and a 6-core 2.6Gh i7 processor and the other is an 8GB dual-core processor 2.2Ghz.
I am looking to get a faster overall speed for STS. The thing that really slows me down is the change event handler process. When it starts running then everything slows down.
There are quite a few one-off guides around for optimal performance tuning of the Spring Tool Suite. Some are written for a Windows platform and some for an OS X platform. Since STS runs on the JVM I thought the optimal settings would work in either environment.
I haven't seen a well-done list of performance tuning options. It would be nice to see if the configuration should change based off of system properties such as RAM, processor, and number of cores.
Has anyone had any success running mongodb on the beaglebone black? do I have to install a different flavor of linux to get this to work or can I use angstrom.
MongoDB (as at 2.4) does not officially support ARM processors. You can watch/upvote SERVER-1811 in the issue tracker, however I wouldn't expect this to get much traction until there are 64-bit server-class ARM processors commonly available.
In general a 32-bit low power ARM processor with limited memory (512Mb RAM on the BeagleBone Black) is not a great fit for a memory-mapped database server like MongoDB. Due to the use of memory-mapped files, 32-bit versions of MongoDB are also limited to about 2GB of data and indexes.
There are some extremely old versions of MongoDB that have been hacked to work on ARM to some extent (eg: MongoDB 2.1.1-pre), which is a very early development release of MongoDB 2.2. I wouldn't recommend this unless you're extremely desperate; likely you will spend far more time trying to get things working than writing productive code.
Better approaches would be to either:
use a database which is designed for lightweight environments (eg. SQLite)
use your BeagleBone to run a MongoDB client application rather than a server
If I install a bare-metal hypervisor (say, ESXi), would it allow me to run Windows 7 concurrently with Linux?
Would it allow me to run multiple instances of Windows 7?
When I'm sitting at the PC that's running Win7 and Linux on a hypervisor, which OS do I see when I look at the screen? (I'm suspecting that the only way to access either OS is to do a remote login.)
Assuming the answer to #2 is yes, how do you manage multiple installs of Win7 on the same hard drive?
Thanks in advance!
If you simply want to run Linux and Windows in parallel you may of course do this on e.g. ESXi. Still, the OSes would run with virtualized (or emulated) hardware available to them, i.e. you would not be able to easily access all the hardware directly and the hypervisor itself not only introduces an overhead but this overhead is not deterministic.
If you want to run an RTOS (like Real-Time Linux) or any other RTOS, then you need a "real-time hypervisor".
You can google for such hypervisors - there are a few out there.
(I dont want to recommend one here as we are a vendor of such a solution our selves)
Regards
GFL
Where can virtualization techniques be applied by an application developer? How can virtualization be applied on a day-to-day basis?
I would like to understand from veteran developers making use of it. I am interested in the following things:
How it helps in development.
How it could be used for testing purposes.
What are the recommended practices.
The main benefit, in my view, is that in a single machine, you can test an application in:
Different OSs, in case your app is multiplatform
Different configurations, like testing a client in one machine and a server in the other, or trying different parameters
Diffferent performance characteristics, like with minimal CPU and RAM, and with multicore and high amounts of RAM
Additionally, you can provide VM images to distribute applications preconfigured, be it for testing or for running applications in virtualized environments, where it makes sense (for apps which do not demand much power)
Can't say I'm a veteran developer, but I've used virtualization extensively when environments need to be controlled. That goes for:
Development: not only is it really useful to have VMs about for different deployment environments (e.g. browser versions, Windows XP / Vista / 7) but especially for maintenance it's handy to have a VM with the right development tools configured for a particular job.
Testing: this is where VMs really shine: it's great to have different deployment environments that can be set back to a known good configuration and multiple server instances running in parallel to test load balancing.
I've also found it useful to have a standard test image available that I can run locally to verify that a fix works. If it doesn't then I can roll back to the previous snapshot with no problems.
I've been using Virtual PC running Windows XP to test products I'm developing. I have clients who still need XP support while my primary dev environment is Vista (haven't had time to jump to Win7 yet), so having a virtual setup for XP is a big time saver.
Before each client drop, I build and test on my Vista dev machine then fire up VPC with XP, drag the binaries to the XP guest OS (enabled by installing Virtual PC additions on the guest OS) and run my tests there. I use the Undo disk feature of Virtual PC so I can always start with a clean XP image. This process would have been really cumbersome without virtualization.
I can now dump my old PCs at the local PC Recycle with no regrets :)
Some sort of test environment: if you are debugging malware (either writing it or developing a pill against it) it is not clever to use the real OS. The only possible disadvantage is that the viruses can detect that they are being run in the virtualization. :( One of the possibilities to do it is because the VM engines can emulate a finite set of hardware.