Can anyone please tell how often blynk local server on raspberry pi write sd card. As everyone know sd card have limited life cycle, so it will be good if we reduce sd card write and dump data every few hour and use ram in between dumping data to card. I don’t need raw data.
How can I reduce sd write ???
Thanks
It probably depends on the data you send… E.G. if you have a vPin registering an uptime clock every second, then it is writing that data every second. The RPi will also be doing it’s own thing in the background as well
You could look at booting off the SD and then running on a small HD… you will have to Google for the how tos of that.
Or just get quality SD cards that claim to be capable of balancing the load.
Or simply plan on cloning and replacing your SD every year or so, For reasonable sizes (as needed by average RPi & Blynk LS use) they are getting almost cheap enough to double as load balancers on wobbly chairs 
thanks for reply
in your reply :: E.G. if you have a vPin registering an uptime clock every second, then it is writing that data every second. ::: Does registering vPin immediately write data on card or flush at interval mentioned in server setting. As mentioned below
Period for flushing all user DB to disk. In millis
profile.save.worker.period=60000
I don’t really know for sure… I suspect it depends on whether you are using RAW DB or not?
All I can say is that in the past I have seen files update on a frequent basis in my own Local Server.
I am unaware of any form of memory buffer, so I still believe the data is “disk” based and other background actions like backup or DB flushing may be in addition to normal realtime data updating.
Others have used Local Servers on RPi for years, but this is the first I recall hearing any concern about it (in reference to Blynk’s Server usage). Have you searched this forum for further info?
You can booting your rpi from flash drive and getting more life
Well, I heard about it, but never ever met such a problem. First aspect, @ngoyat is that those Linux distros for SBC’s are usually optimised to work with flash drives. Sure there is always a field to optimise further (like logs on RAM disks- used for example by dietpi distro) or switching off all logging except kernel. The second is, the SD cards are not that wear prone as you might think. I’m using one in my car DVR for quite a few years and it is still OK and in this case a whole SD card is rewritten once a week or so. I guess the quality of SD card matters. I’m not here to advertise any, but I do have some bad memories with one, reputable brand, while I’ve never met any trouble with other reputable even more 
My server is running for some 2 years for now (or even more?) and it is also serving: (aside from Blynk) mosquito, node-red, miniDlna, Samba server (not heavily accessed) and from time to time Jdowloader.
I’m sure it is not immediate. While I’m not using 1sec for pushing the data (only for reading) I can clearly see when the SD is accessed and it is relatively rarely accessed: once a minute or so.
Correct… although the finest resolution of the file access is ONLY in minutes… so hard to say for sure in my case if the file is being rewritten more frequently.
Of course, I think these are only showing the SuperChart data… thus yes, 1 minute value resolution.
But again, does that equate the writing frequency of the master user file? As it seems to contain all latest vPin data values, even my once a second ones.
I agree with this as well… I think this general OP topic’s concern is overrated… just don’t expect it to run forever 
and make backups.
If you install iostat (it’s in the sysstat bundle) you can check how many writes you have on your system:
pi@raspberrypi:~ $ sudo apt-get install sysstat
On a fresh Debian install I’ve got about 1 write every 5 second on an idling system (no Blynk or other server):
Or as @Gunner would have done it:
Blynk might be the straw that breaks the camels back, but the systems general writes is far more frequent (and potentially harmfull).
Thanks @distans for yet more linux support 
I ran your way… still interpreting “my” way 
I have this on my RPi3, running a Server and two Clients (NodeJS and Python)
Since I have at least 3-4 projects running “uptime in seconds” displays, there must be some form of RAM buffer then.
Thanks all of you. Currently i am using hdd with raspberry pi 2 model b , and want to switch to pi zero w, that’s why i am asking
Really appreciate attention given to topic 
This is where it gets tricky and outside my comfort zone! 
Uptime is read from /proc/uptime, which looks like a real file but it is, of course, not a real file! When accessed the values are generated on the fly from the kernel.
From the manual page for proc (pi@raspberrypi:~ $ man proc) you’ll see this:
The proc filesystem is a pseudo-filesystem which provides an interface to kernel data structures. It is commonly mounted at /proc. Most of it is read-only, but some files allow kernel variables to be changed.
So my guess is that uptime doesn’t affect the values of iostat.
My term uptime is in reference to my sending an incrementing value to a Display Widget every second from my sketch (based on that devices internal timers since boot)… The data shows every second in the App (although I probably could increase that frequency, to a limit, to test), thus must be updating in the master user file in the server every second… and even more frequently if from multiple devices that are not synchronized in their startup times.
I honestly think the file is being written as frequently as needed… it is just that most “time” references for seeing such statistics is limited to rounded seconds.
Well, of course it is… 
Probably. Guessing software developers wants to minimize r/w’s because it’s slower.
“0,71 w/s” doesn’t look all that rounded to me.
True 
I think in my mind I was referring to the timestamps on all the “last accessed” file/folder info that is most commonly seen when looking at such stuff… However, looking back at my screenshots, even those are usually rounded minutes… so… whatever
Regardless if we accept the mission, our SD cards will self destruct at the end of this message… 
1 Like
Hmmm… in my case it is 0,27 (~4 times per second)with all the above stuff up and running. But the onboard led tied to mmcblk0 lights up not more than once per 30secs or so. Can it be some RAM buffer is involved?
You’re reading it incorrect, that’s is ONCE every ~4 second 
Probably. I haven’t spent so much time using and tweaking the RPI since I only have “mine” as a loan (helping a friend with some Z-wave stuff (of which I know nothing about 
)). Don’t even know which LED are connected to what function 
naturally! What a mistake…
1 Like