Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "Operations" page has been changed by RobertColi.
The comment on this change is: some clarification of the OR in the snapshotting 
issue (fixed in 0.7.-beta2/CASSANDRA-1371) and numbered steps for restore.
http://wiki.apache.org/cassandra/Operations?action=diff&rev1=63&rev2=64

--------------------------------------------------

  {{{
  Exception in thread "main" java.io.IOException: Cannot run program "ln": 
java.io.IOException: error=12, Cannot allocate memory
  }}}
- Remain calm. The operating system is trying to allocate for the "ln" process 
a memory space as large as the parent process (the cassandra server), even if 
'''it's not going to use it'''. So if you have a machine with 8GB of RAM and no 
swap, and you gave 6 to the cassandra server, it will fail during this because 
the operating system will wan 12 GB of memory before allowing you to create the 
process.
+ This is caused by the operating system trying to allocate the child "ln" 
process a memory space as large as the parent process (the cassandra server), 
even though '''it's not going to use it'''. So if you have a machine with 8GB 
of RAM and no swap, and you gave 6GB to the cassandra server, it will fail 
during this because the operating system wants 12 GB of virtual memory before 
allowing you to create the process. 
  
- This can be worked around depending on the operating system by either 
creating a swap file, snapshotting, turning it off or by turning on "memory 
overcommit". Since the child process memory is the same as the parent, until it 
performs an `exec("ln")` call the operating system will not use the new memory 
and will just refer to the old one, and everything will work.
+ This error can be worked around (depending on the operating system by either :
  
- To revert to a snapshot, shut down the node, clear out the old commitlog and 
sstables, and move the sstables from the snapshot location to the live data 
directory.
+  * creating a swap file, snapshotting, removing swap file
+ OR
+  * turning on "memory overcommit"
+ 
+ To revert to a snapshot:
+ 
+  1. shut down the node
+  1. clear out the old commitlog and sstables
+  1. move the sstables from the snapshot location to the live data directory.
  
  === Consistent backups ===
  You can get an eventually consistent backup by snapshotting all node; no 
individual node's backup is guaranteed to be consistent but if you restore from 
that snapshot then clients will get eventually consistent behavior as usual.

Reply via email to