Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
vms:webdev:apache [2015/08/04 12:40] admin [System Level Caching] |
vms:webdev:apache [2017/03/31 15:13] (current) admin ↷ Links adapted because of a move operation |
||
|---|---|---|---|
| Line 235: | Line 235: | ||
| > sudo mount -t vboxsf <www-share> </path/to/montpoint> | > sudo mount -t vboxsf <www-share> </path/to/montpoint> | ||
| </code> | </code> | ||
| + | |||
| + | <WRAP center round tip> | ||
| + | In case at this point you run into a mount error of type: | ||
| + | <code> | ||
| + | mount: unknown filesystem type 'vboxsf' | ||
| + | </code> | ||
| + | |||
| + | You need to install the VirtualBox Guest Additions, see the [[vms:python:django#install_virtualbox_guest_additions| Install VirtualBox Guest Additions]] section on this wiki. | ||
| + | </WRAP> | ||
| + | |||
| ----- | ----- | ||
| ===== Setting Permissions and Mount Options ===== | ===== Setting Permissions and Mount Options ===== | ||
| Line 537: | Line 547: | ||
| This didn't completely resolved the problem on my configuration.\\ | This didn't completely resolved the problem on my configuration.\\ | ||
| - | It turned out the problem came from the VM Linux system itself, it was somehow caching the operation. Luckily I found [[http://serverfault.com/questions/163894/file-change-on-a-lamp-development-server-not-taken-into-account|this post on ServerFault]], coming with the //sync; echo 3 > /proc/sys/vm/drop_caches // command that effectively solved this issue. It is possible to "manually" launch the command repeatedly using the //watch -n // command. We could also have a cron script running all the time, avoiding the need of the manual launch of the //watch// command. | + | It turned out the problem came from the VM Linux system itself, it was somehow caching the operation. Luckily I found [[http://serverfault.com/questions/163894/file-change-on-a-lamp-development-server-not-taken-into-account|this post on ServerFault]], coming with the //sync; echo 3 > /proc/sys/vm/drop_caches // command that effectively solved this issue. It is possible to "manually" launch the command repeatedly using the //watch -n // command to clean the system cache every second: |
| <code> | <code> | ||
| > watch -n 1 'sync; echo 3 > /proc/sys/vm/drop_caches' | > watch -n 1 'sync; echo 3 > /proc/sys/vm/drop_caches' | ||
| </code> | </code> | ||
| - | Will clean the system cache every second. | + | We could also have a bash script running an endless loop every second, avoiding the need of the manual launch of the //watch// command. To this purpose, we'll create a shell //**drop_caches.sh**// script file and put in an //**@reboot cron task**// (following commands assumed as root): |
| + | <code> | ||
| + | > nano /etc/init.d/drop_caches.sh | ||
| + | |||
| + | PASTE: | ||
| + | #!/bin/bash | ||
| + | sync; echo 3 > /proc/sys/vm/drop_caches | ||
| + | |||
| + | > chmod +x ~/scripts/drop_caches.sh | ||
| + | > crontab -e | ||
| + | |||
| + | PASTE: | ||
| + | @reboot /root/scripts/drop_caches.sh | ||
| + | |||
| + | > reboot | ||
| + | </code> | ||
| + | |||
| + | To make sure that the script is well running after reboot: | ||
| + | <code> | ||
| + | > ps aux | grep [c]aches | ||
| + | root 2260 0.0 0.0 4184 576 ? Ss 02:50 0:00 /bin/sh -c /root/scripts/drop_caches.sh | ||
| + | root 2266 0.3 0.1 10768 1412 ? S 02:50 0:00 /bin/bash /root/scripts/drop_caches.sh | ||
| + | </code> | ||
