欧美性猛交xxxx免费看_牛牛在线视频国产免费_天堂草原电视剧在线观看免费_国产粉嫩高清在线观看_国产欧美日本亚洲精品一5区

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

進(jìn)程寫文件會(huì)丟失數(shù)據(jù)嗎

科技綠洲 ? 來源:Linux開發(fā)架構(gòu)之路 ? 作者:Linux開發(fā)架構(gòu)之路 ? 2023-11-13 10:57 ? 次閱讀

進(jìn)程寫文件(使用緩沖 IO)過程中,寫一半的時(shí)候,進(jìn)程發(fā)生了崩潰,會(huì)丟失數(shù)據(jù)嗎?

答案,是不會(huì)的。

圖片

因?yàn)檫M(jìn)程在執(zhí)行 write (使用緩沖 IO)系統(tǒng)調(diào)用的時(shí)候,實(shí)際上是將文件數(shù)據(jù)寫到了內(nèi)核的 page cache,它是文件系統(tǒng)中用于緩存文件數(shù)據(jù)的緩沖,所以即使進(jìn)程崩潰了,文件數(shù)據(jù)還是保留在內(nèi)核的 page cache,我們讀數(shù)據(jù)的時(shí)候,也是從內(nèi)核的 page cache 讀取,因此還是依然讀的進(jìn)程崩潰前寫入的數(shù)據(jù)。

內(nèi)核會(huì)找個(gè)合適的時(shí)機(jī),將 page cache 中的數(shù)據(jù)持久化到磁盤。但是如果 page cache 里的文件數(shù)據(jù),在持久化到磁盤化到磁盤之前,系統(tǒng)發(fā)生了崩潰,那這部分?jǐn)?shù)據(jù)就會(huì)丟失了。

當(dāng)然, 我們也可以在程序里調(diào)用 fsync 函數(shù),在寫文文件的時(shí)候,立刻將文件數(shù)據(jù)持久化到磁盤,這樣就可以解決系統(tǒng)崩潰導(dǎo)致的文件數(shù)據(jù)丟失的問題。

  1. Page Cache

1.1 Page Cache 是什么?

為了理解 Page Cache,我們不妨先看一下 Linux 的文件 I/O 系統(tǒng),如下圖所示:

圖片

Figure1. Linux 文件 I/O 系統(tǒng)

上圖中,紅色部分為 Page Cache。可見 Page Cache 的本質(zhì)是由 Linux 內(nèi)核管理的內(nèi)存區(qū)域。我們通過 mmap 以及 buffered I/O 將文件讀取到內(nèi)存空間實(shí)際上都是讀取到 Page Cache 中。

1.2 如何查看系統(tǒng)的 Page Cache?

通過讀取 /proc/meminfo 文件,能夠?qū)崟r(shí)獲取系統(tǒng)內(nèi)存情況:

$ cat /proc/meminfo
...
Buffers:            1224 kB
Cached:           111472 kB
SwapCached:        36364 kB
Active:          6224232 kB
Inactive:         979432 kB
Active(anon):    6173036 kB
Inactive(anon):   927932 kB
Active(file):      51196 kB
Inactive(file):    51500 kB
...
Shmem:             10000 kB
...
SReclaimable:      43532 kB
...

根據(jù)上面的數(shù)據(jù),你可以簡(jiǎn)單得出這樣的公式(等式兩邊之和都是 112696 KB):

Buffers + Cached + SwapCached = Active(file) + Inactive(file) + Shmem + SwapCached

兩邊等式都是 Page Cache,即:

Page Cache = Buffers + Cached + SwapCached

通過閱讀 1.4 以及 1.5 小節(jié),就能夠理解為什么 SwapCached 與 Buffers 也是 Page Cache 的一部分。

1.3 page 與 Page Cache

page 是內(nèi)存管理分配的基本單位, Page Cache 由多個(gè) page 構(gòu)成。page 在操作系統(tǒng)中通常為 4KB 大小(32bits/64bits),而 Page Cache 的大小則為 4KB 的整數(shù)倍。

另一方面,并不是所有 page 都被組織為 Page Cache。

Linux 系統(tǒng)上供用戶可訪問的內(nèi)存分為兩個(gè)類型[2],即:

  • File-backed pages:文件備份頁也就是 Page Cache 中的 page,對(duì)應(yīng)于磁盤上的若干數(shù)據(jù)塊;對(duì)于這些頁最大的問題是臟頁回盤;
  • Anonymous pages:匿名頁不對(duì)應(yīng)磁盤上的任何磁盤數(shù)據(jù)塊,它們是進(jìn)程的運(yùn)行是內(nèi)存空間(例如方法棧、局部變量表等屬性);

為什么 Linux 不把 Page Cache 稱為 block cache,這不是更好嗎?

這是因?yàn)閺拇疟P中加載到內(nèi)存的數(shù)據(jù)不僅僅放在 Page Cache 中,還放在 buffer cache 中。例如通過 Direct I/O 技術(shù)的磁盤文件就不會(huì)進(jìn)入 Page Cache 中。當(dāng)然,這個(gè)問題也有 Linux 歷史設(shè)計(jì)的原因,畢竟這只是一個(gè)稱呼,含義隨著 Linux 系統(tǒng)的演進(jìn)也逐漸不同。

下面比較一下 File-backed pages 與 Anonymous pages 在 Swap 機(jī)制下的性能。

內(nèi)存是一種珍惜資源,當(dāng)內(nèi)存不夠用時(shí),內(nèi)存管理單元(Memory Mangament Unit)需要提供調(diào)度算法來回收相關(guān)內(nèi)存空間。內(nèi)存空間回收的方式通常就是 swap,即交換到持久化存儲(chǔ)設(shè)備上。

File-backed pages(Page Cache)的內(nèi)存回收代價(jià)較低。Page Cache 通常對(duì)應(yīng)于一個(gè)文件上的若干順序塊,因此可以通過順序 I/O 的方式落盤。另一方面,如果 Page Cache 上沒有進(jìn)行寫操作(所謂的沒有臟頁),甚至不會(huì)將 Page Cache 回盤,因?yàn)閿?shù)據(jù)的內(nèi)容完全可以通過再次讀取磁盤文件得到。

Page Cache 的主要難點(diǎn)在于臟頁回盤,這個(gè)內(nèi)容會(huì)在第二節(jié)進(jìn)行詳細(xì)說明。

Anonymous pages 的內(nèi)存回收代價(jià)較高。這是因?yàn)?Anonymous pages 通常隨機(jī)地寫入持久化交換設(shè)備。另一方面,無論是否有寫操作,為了確保數(shù)據(jù)不丟失,Anonymous pages 在 swap 時(shí)必須持久化到磁盤。

1.4 Swap 與缺頁中斷

Swap 機(jī)制指的是當(dāng)物理內(nèi)存不夠用,內(nèi)存管理單元(Memory Mangament Unit,MMU)需要提供調(diào)度算法來回收相關(guān)內(nèi)存空間,然后將清理出來的內(nèi)存空間給當(dāng)前內(nèi)存申請(qǐng)方。

Swap 機(jī)制存在的本質(zhì)原因是 Linux 系統(tǒng)提供了虛擬內(nèi)存管理機(jī)制,每一個(gè)進(jìn)程認(rèn)為其獨(dú)占內(nèi)存空間,因此所有進(jìn)程的內(nèi)存空間之和遠(yuǎn)遠(yuǎn)大于物理內(nèi)存。所有進(jìn)程的內(nèi)存空間之和超過物理內(nèi)存的部分就需要交換到磁盤上。

操作系統(tǒng)以 page 為單位管理內(nèi)存,當(dāng)進(jìn)程發(fā)現(xiàn)需要訪問的數(shù)據(jù)不在內(nèi)存時(shí),操作系統(tǒng)可能會(huì)將數(shù)據(jù)以頁的方式加載到內(nèi)存中。上述過程被稱為缺頁中斷,當(dāng)操作系統(tǒng)發(fā)生缺頁中斷時(shí),就會(huì)通過系統(tǒng)調(diào)用將 page 再次讀到內(nèi)存中。

但主內(nèi)存的空間是有限的,當(dāng)主內(nèi)存中不包含可以使用的空間時(shí),操作系統(tǒng)會(huì)從選擇合適的物理內(nèi)存頁驅(qū)逐回磁盤,為新的內(nèi)存頁讓出位置,選擇待驅(qū)逐頁的過程在操作系統(tǒng)中叫做頁面替換(Page Replacement),替換操作又會(huì)觸發(fā) swap 機(jī)制。

如果物理內(nèi)存足夠大,那么可能不需要 Swap 機(jī)制,但是 Swap 在這種情況下還是有一定優(yōu)勢(shì):對(duì)于有發(fā)生內(nèi)存泄漏幾率的應(yīng)用程序(進(jìn)程),Swap 交換分區(qū)更是重要,這可以確保內(nèi)存泄露不至于導(dǎo)致物理內(nèi)存不夠用,最終導(dǎo)致系統(tǒng)崩潰。但內(nèi)存泄露會(huì)引起頻繁的 swap,此時(shí)非常影響操作系統(tǒng)的性能。

Linux 通過一個(gè) swappiness 參數(shù)來控制 Swap 機(jī)制[2]:這個(gè)參數(shù)值可為 0-100,控制系統(tǒng) swap 的優(yōu)先級(jí):

  • 高數(shù)值:較高頻率的 swap,進(jìn)程不活躍時(shí)主動(dòng)將其轉(zhuǎn)換出物理內(nèi)存。
  • 低數(shù)值:較低頻率的 swap,這可以確保交互式不因?yàn)閮?nèi)存空間頻繁地交換到磁盤而提高響應(yīng)延遲。

最后,為什么 Buffers 也是 Page Cache 的一部分?

這是因?yàn)楫?dāng)匿名頁(Inactive(anon) 以及 Active(anon))先被交換(swap out)到磁盤上后,然后再加載回(swap in)內(nèi)存中,由于讀入到內(nèi)存后原來的 Swap File 還在,所以 SwapCached 也可以認(rèn)為是 File-backed page,即屬于 Page Cache。這個(gè)過程如 Figure 2 所示。

圖片

Figure2. 匿名頁的被交換后也是 Page Cache

1.5 Page Cache 與 buffer cache

執(zhí)行 free 命令,注意到會(huì)有兩列名為 buffers 和 cached,也有一行名為 “-/+ buffers/cache”。

~ free -m
             total       used       free     shared    buffers     cached
Mem:        128956      96440      32515          0       5368      39900
-/+ buffers/cache:      51172      77784
Swap:        16002          0      16001

其中,cached 列表示當(dāng)前的頁緩存(Page Cache)占用量,buffers 列表示當(dāng)前的塊緩存(buffer cache)占用量。用一句話來解釋:Page Cache 用于緩存文件的頁數(shù)據(jù),buffer cache 用于緩存塊設(shè)備(如磁盤)的塊數(shù)據(jù)。頁是邏輯上的概念,因此 Page Cache 是與文件系統(tǒng)同級(jí)的;塊是物理上的概念,因此 buffer cache 是與塊設(shè)備驅(qū)動(dòng)程序同級(jí)的。

其中,cached 列表示當(dāng)前的頁緩存(Page Cache)占用量,buffers 列表示當(dāng)前的塊緩存(buffer cache)占用量。用一句話來解釋:Page Cache 用于緩存文件的頁數(shù)據(jù),buffer cache 用于緩存塊設(shè)備(如磁盤)的塊數(shù)據(jù)。頁是邏輯上的概念,因此 Page Cache 是與文件系統(tǒng)同級(jí)的;塊是物理上的概念,因此 buffer cache 是與塊設(shè)備驅(qū)動(dòng)程序同級(jí)的。

Page Cache 與 buffer cache 的共同目的都是加速數(shù)據(jù) I/O:寫數(shù)據(jù)時(shí)首先寫到緩存,將寫入的頁標(biāo)記為 dirty,然后向外部存儲(chǔ) flush,也就是緩存寫機(jī)制中的 write-back(另一種是 write-through,Linux 默認(rèn)情況下不采用);讀數(shù)據(jù)時(shí)首先讀取緩存,如果未命中,再去外部存儲(chǔ)讀取,并且將讀取來的數(shù)據(jù)也加入緩存。操作系統(tǒng)總是積極地將所有空閑內(nèi)存都用作 Page Cache 和 buffer cache,當(dāng)內(nèi)存不夠用時(shí)也會(huì)用 LRU 等算法淘汰緩存頁。

在 Linux 2.4 版本的內(nèi)核之前,Page Cache 與 buffer cache 是完全分離的。但是,塊設(shè)備大多是磁盤,磁盤上的數(shù)據(jù)又大多通過文件系統(tǒng)來組織,這種設(shè)計(jì)導(dǎo)致很多數(shù)據(jù)被緩存了兩次,浪費(fèi)內(nèi)存。所以在 2.4 版本內(nèi)核之后,兩塊緩存近似融合在了一起:如果一個(gè)文件的頁加載到了 Page Cache,那么同時(shí) buffer cache 只需要維護(hù)塊指向頁的指針就可以了。只有那些沒有文件表示的塊,或者繞過了文件系統(tǒng)直接操作(如dd命令)的塊,才會(huì)真正放到 buffer cache 里。因此,我們現(xiàn)在提起 Page Cache,基本上都同時(shí)指 Page Cache 和 buffer cache 兩者,本文之后也不再區(qū)分,直接統(tǒng)稱為 Page Cache。

下圖近似地示出 32-bit Linux 系統(tǒng)中可能的一種 Page Cache 結(jié)構(gòu),其中 block size 大小為 1KB,page size 大小為 4KB。

圖片

Page Cache 中的每個(gè)文件都是一棵基數(shù)樹(radix tree,本質(zhì)上是多叉搜索樹),樹的每個(gè)節(jié)點(diǎn)都是一個(gè)頁。根據(jù)文件內(nèi)的偏移量就可以快速定位到所在的頁,如下圖所示。關(guān)于基數(shù)樹的原理可以參見英文維基,這里就不細(xì)說了。

圖片

1.6 Page Cache 與預(yù)讀

操作系統(tǒng)為基于 Page Cache 的讀緩存機(jī)制提供預(yù)讀機(jī)制(PAGE_READAHEAD),一個(gè)例子是:

  • 用戶線程僅僅請(qǐng)求讀取磁盤上文件 A 的 offset 為 0-3KB 范圍內(nèi)的數(shù)據(jù),由于磁盤的基本讀寫單位為 block(4KB),于是操作系統(tǒng)至少會(huì)讀 0-4KB 的內(nèi)容,這恰好可以在一個(gè) page 中裝下。
  • 但是操作系統(tǒng)出于局部性原理[3]會(huì)選擇將磁盤塊 offset [4KB,8KB)、[8KB,12KB) 以及 [12KB,16KB) 都加載到內(nèi)存,于是額外在內(nèi)存中申請(qǐng)了 3 個(gè) page;

下圖代表了操作系統(tǒng)的預(yù)讀機(jī)制:

圖片

Figure.操作系統(tǒng)的預(yù)讀機(jī)制;

上圖中,應(yīng)用程序利用 read 系統(tǒng)調(diào)動(dòng)讀取 4KB 數(shù)據(jù),實(shí)際上內(nèi)核使用 readahead 機(jī)制完成了 16KB 數(shù)據(jù)的讀取。

  1. Page Cache 與文件持久化的一致性&可靠性

現(xiàn)代 Linux 的 Page Cache 正如其名,是對(duì)磁盤上 page(頁)的內(nèi)存緩存,同時(shí)可以用于讀/寫操作。任何系統(tǒng)引入緩存,就會(huì)引發(fā)一致性問題:內(nèi)存中的數(shù)據(jù)與磁盤中的數(shù)據(jù)不一致,例如常見后端架構(gòu)中的 Redis 緩存與 MySQL 數(shù)據(jù)庫就存在一致性問題。

Linux 提供多種機(jī)制來保證數(shù)據(jù)一致性,但無論是單機(jī)上的內(nèi)存與磁盤一致性,還是分布式組件中節(jié)點(diǎn) 1 與節(jié)點(diǎn) 2 、節(jié)點(diǎn) 3 的數(shù)據(jù)一致性問題,理解的關(guān)鍵是 trade-off:吞吐量與數(shù)據(jù)一致性保證是一對(duì)矛盾。

首先,需要我們理解一下文件的數(shù)據(jù)。文件 = 數(shù)據(jù) + 元數(shù)據(jù)。元數(shù)據(jù)用來描述文件的各種屬性,也必須存儲(chǔ)在磁盤上。因此,我們說保證文件一致性其實(shí)包含了兩個(gè)方面:數(shù)據(jù)一致+元數(shù)據(jù)一致。

文件的元數(shù)據(jù)包括:文件大小、創(chuàng)建時(shí)間、訪問時(shí)間、屬主屬組等信息

我們考慮如下一致性問題:如果發(fā)生寫操作并且對(duì)應(yīng)的數(shù)據(jù)在 Page Cache 中,那么寫操作就會(huì)直接作用于 Page Cache 中,此時(shí)如果數(shù)據(jù)還沒刷新到磁盤,那么內(nèi)存中的數(shù)據(jù)就領(lǐng)先于磁盤,此時(shí)對(duì)應(yīng) page 就被稱為 Dirty page。

當(dāng)前 Linux 下以兩種方式實(shí)現(xiàn)文件一致性:

  • Write Through(寫穿):向用戶層提供特定接口,應(yīng)用程序可主動(dòng)調(diào)用接口來保證文件一致性;
  • Write back(寫回):系統(tǒng)中存在定期任務(wù)(表現(xiàn)形式為內(nèi)核線程),周期性地同步文件系統(tǒng)中文件臟數(shù)據(jù)塊,這是默認(rèn)的 Linux 一致性方案;

上述兩種方式最終都依賴于系統(tǒng)調(diào)用,主要分為如下三種系統(tǒng)調(diào)用:

圖片

上述三種系統(tǒng)調(diào)用可以分別由用戶進(jìn)程與內(nèi)核進(jìn)程發(fā)起。下面我們研究一下內(nèi)核線程的相關(guān)特性。

  • 創(chuàng)建的針對(duì)回寫任務(wù)的內(nèi)核線程數(shù)由系統(tǒng)中持久存儲(chǔ)設(shè)備決定,為每個(gè)存儲(chǔ)設(shè)備創(chuàng)建單獨(dú)的刷新線程;
  • 關(guān)于多線程的架構(gòu)問題,Linux 內(nèi)核采取了 Lighthttp 的做法,即系統(tǒng)中存在一個(gè)管理線程和多個(gè)刷新線程(每個(gè)持久存儲(chǔ)設(shè)備對(duì)應(yīng)一個(gè)刷新線程)。管理線程監(jiān)控設(shè)備上的臟頁面情況,若設(shè)備一段時(shí)間內(nèi)沒有產(chǎn)生臟頁面,就銷毀設(shè)備上的刷新線程;若監(jiān)測(cè)到設(shè)備上有臟頁面需要回寫且尚未為該設(shè)備創(chuàng)建刷新線程,那么創(chuàng)建刷新線程處理臟頁面回寫。而刷新線程的任務(wù)較為單調(diào),只負(fù)責(zé)將設(shè)備中的臟頁面回寫至持久存儲(chǔ)設(shè)備中。
  • 刷新線程刷新設(shè)備上臟頁面大致設(shè)計(jì)如下:
  • 每個(gè)設(shè)備保存臟文件鏈表,保存的是該設(shè)備上存儲(chǔ)的臟文件的 inode 節(jié)點(diǎn)。所謂的回寫文件臟頁面即回寫該 inode 鏈表上的某些文件的臟頁面;
  • 系統(tǒng)中存在多個(gè)回寫時(shí)機(jī),第一是應(yīng)用程序主動(dòng)調(diào)用回寫接口(fsync,fdatasync 以及 sync 等),第二管理線程周期性地喚醒設(shè)備上的回寫線程進(jìn)行回寫,第三是某些應(yīng)用程序/內(nèi)核任務(wù)發(fā)現(xiàn)內(nèi)存不足時(shí)要回收部分緩存頁面而事先進(jìn)行臟頁面回寫,設(shè)計(jì)一個(gè)統(tǒng)一的框架來管理這些回寫任務(wù)非常有必要。

Write Through 與 Write back 在持久化的可靠性上有所不同:

  • Write Through 以犧牲系統(tǒng) I/O 吞吐量作為代價(jià),向上層應(yīng)用確保一旦寫入,數(shù)據(jù)就已經(jīng)落盤,不會(huì)丟失;
  • Write back 在系統(tǒng)發(fā)生宕機(jī)的情況下無法確保數(shù)據(jù)已經(jīng)落盤,因此存在數(shù)據(jù)丟失的問題。不過,在程序掛了,例如被 kill -9,Page Cache 中的數(shù)據(jù)操作系統(tǒng)還是會(huì)確保落盤;
  1. Page Cache 的優(yōu)劣勢(shì)

3.1 Page Cache 的優(yōu)勢(shì)

1.加快數(shù)據(jù)訪問

如果數(shù)據(jù)能夠在內(nèi)存中進(jìn)行緩存,那么下一次訪問就不需要通過磁盤 I/O 了,直接命中內(nèi)存緩存即可。

由于內(nèi)存訪問比磁盤訪問快很多,因此加快數(shù)據(jù)訪問是 Page Cache 的一大優(yōu)勢(shì)。

2.減少 I/O 次數(shù),提高系統(tǒng)磁盤 I/O 吞吐量

得益于 Page Cache 的緩存以及預(yù)讀能力,而程序又往往符合局部性原理,因此通過一次 I/O 將多個(gè) page 裝入 Page Cache 能夠減少磁盤 I/O 次數(shù), 進(jìn)而提高系統(tǒng)磁盤 I/O 吞吐量。

3.2 Page Cache 的劣勢(shì)

page cache 也有其劣勢(shì),最直接的缺點(diǎn)是需要占用額外物理內(nèi)存空間,物理內(nèi)存在比較緊俏的時(shí)候可能會(huì)導(dǎo)致頻繁的 swap 操作,最終導(dǎo)致系統(tǒng)的磁盤 I/O 負(fù)載的上升。

Page Cache 的另一個(gè)缺陷是對(duì)應(yīng)用層并沒有提供很好的管理 API,幾乎是透明管理。應(yīng)用層即使想優(yōu)化 Page Cache 的使用策略也很難進(jìn)行。因此一些應(yīng)用選擇在用戶空間實(shí)現(xiàn)自己的 page 管理,而不使用 page cache,例如 MySQL InnoDB 存儲(chǔ)引擎以 16KB 的頁進(jìn)行管理。

Page Cache 最后一個(gè)缺陷是在某些應(yīng)用場(chǎng)景下比 Direct I/O 多一次磁盤讀 I/O 以及磁盤寫 I/O。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 數(shù)據(jù)
    +關(guān)注

    關(guān)注

    8

    文章

    7184

    瀏覽量

    89723
  • 緩沖
    +關(guān)注

    關(guān)注

    0

    文章

    53

    瀏覽量

    17867
  • 磁盤
    +關(guān)注

    關(guān)注

    1

    文章

    380

    瀏覽量

    25299
  • 系統(tǒng)調(diào)用

    關(guān)注

    0

    文章

    28

    瀏覽量

    8359
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    Linux如何查看文件是被那個(gè)進(jìn)程占用數(shù)據(jù)?

    文件被那個(gè)進(jìn)程使用,數(shù)據(jù)不是用lsof可以找出來嗎,但現(xiàn)實(shí)情況是lsof沒找出來T_T
    發(fā)表于 10-27 09:17 ?530次閱讀

    【Linux學(xué)習(xí)雜談】之父子進(jìn)程對(duì)文件的操作

    父子進(jìn)程對(duì)文件的操作: 1.子進(jìn)程繼承父進(jìn)程中打開的文件。 前提是父進(jìn)程中將
    發(fā)表于 09-01 20:37

    labview串口讀取高頻率數(shù)據(jù)再保存會(huì)丟失數(shù)據(jù)

    串口讀取數(shù)據(jù),數(shù)據(jù)一秒40多次寫入,在讀取的同時(shí)還保存到txt文件,但是會(huì)丟失一部分數(shù)據(jù),有高手
    發(fā)表于 11-04 09:32

    Linux進(jìn)程退出之方法論

    對(duì)應(yīng)每一個(gè)打開的文件,在內(nèi)存中都有一片緩沖區(qū)。每次讀文件時(shí),會(huì)連續(xù)的讀出若干條記錄,這樣在下次讀文件時(shí)就可以直接從內(nèi)存的緩沖區(qū)讀?。煌瑯?,每次
    發(fā)表于 10-26 21:45

    LabView隊(duì)列操作程序數(shù)據(jù)會(huì)丟失,請(qǐng)問有什么好的改進(jìn)方法減少數(shù)據(jù)丟失呢?

    本帖最后由 一只耳朵怪 于 2018-6-21 16:01 編輯 各位大神,我寫了一個(gè)隊(duì)列操作,以便讀取的光譜數(shù)據(jù)能夠慢一點(diǎn)的寫入TDMS文件中,但是程序在運(yùn)行過程中部分數(shù)據(jù)會(huì)
    發(fā)表于 06-21 08:14

    請(qǐng)問文件怎么會(huì)丟失呢?

    ,那么文件怎么會(huì)丟失呢? 以上來自于百度翻譯 以下為原文 I copied the subject line from mjarabek's posting about v1.40, from
    發(fā)表于 06-17 07:54

    CAN轉(zhuǎn)LWIP會(huì)丟失數(shù)據(jù)

    各位大神,我用407的開發(fā)板做了一個(gè)CAN轉(zhuǎn)以太網(wǎng)的程序。程序不帶操作系統(tǒng),CAN是用中斷做的,LWIP就是用例程的發(fā)送。實(shí)際測(cè)試發(fā)現(xiàn)當(dāng)LWIP發(fā)送的時(shí)候。CAN中斷接收會(huì)丟失數(shù)據(jù),我個(gè)人認(rèn)為是有
    發(fā)表于 04-03 04:35

    LabVIEW中For循環(huán)會(huì)丟失數(shù)據(jù)

    LabVIEW中For循環(huán)會(huì)丟失數(shù)據(jù)LabVIEW程序中包含一個(gè)For循環(huán),有時(shí)循環(huán)會(huì)丟失數(shù)據(jù),
    發(fā)表于 02-01 13:00

    微軟Windows 10修復(fù)補(bǔ)丁KB4532693會(huì)導(dǎo)致文件丟失

    2月11日,微軟為Windows 10發(fā)布了具有重要安全修復(fù)程序的累積更新補(bǔ)丁KB4532693,但該補(bǔ)丁會(huì)導(dǎo)致用戶升級(jí)后桌面、帳號(hào)配置文件丟失。
    的頭像 發(fā)表于 02-26 08:12 ?2571次閱讀

    查看Linux文件占用進(jìn)程數(shù)據(jù)

      centos7 在某一段時(shí)間監(jiān)控報(bào)警磁盤使用率達(dá)99%,由于監(jiān)控屬于概要形式信息,沒有快照信息的監(jiān)控(能發(fā)現(xiàn)某進(jìn)程的I/O,CPU消耗情況),所以需要在服務(wù)器上去定時(shí)執(zhí)行統(tǒng)計(jì)命令獲取快照信息
    的頭像 發(fā)表于 11-04 16:46 ?874次閱讀

    虛擬機(jī)文件丟失導(dǎo)致Hyper-V服務(wù)癱瘓的數(shù)據(jù)恢復(fù)案例

    虛擬機(jī)文件丟失導(dǎo)致Hyper-V服務(wù)癱瘓的數(shù)據(jù)恢復(fù)案例
    的頭像 發(fā)表于 02-14 15:11 ?721次閱讀
    虛擬機(jī)<b class='flag-5'>文件</b><b class='flag-5'>丟失</b>導(dǎo)致Hyper-V服務(wù)癱瘓的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    SQL Server數(shù)據(jù)庫文件丟失數(shù)據(jù)恢復(fù)案例

    未知原因?qū)е耂ql Server數(shù)據(jù)庫文件丟失,涉及到數(shù)個(gè)數(shù)據(jù)庫和數(shù)千張表,不能確定數(shù)據(jù)存儲(chǔ)位置。數(shù)據(jù)庫文件
    的頭像 發(fā)表于 04-28 14:53 ?1056次閱讀
    SQL Server<b class='flag-5'>數(shù)據(jù)庫文件</b><b class='flag-5'>丟失</b>的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    如何利用Mutex解決并發(fā)文件亂序的問題?

    在實(shí)際開發(fā)過程中,我們可能會(huì)遇到并發(fā)文件的場(chǎng)景,如果處理不當(dāng)很可能出現(xiàn)文件內(nèi)容亂序問題。
    的頭像 發(fā)表于 08-12 09:54 ?686次閱讀

    PLC數(shù)據(jù)丟失如何找回?

    還原到PLC中,以恢復(fù)丟失數(shù)據(jù)。 (2)PLC日志文件:某些PLC系統(tǒng)會(huì)記錄運(yùn)行時(shí)的日志文件,其中包含了關(guān)鍵的操作和
    的頭像 發(fā)表于 09-05 10:30 ?4028次閱讀

    數(shù)據(jù)數(shù)據(jù)恢復(fù)—Sql Server數(shù)據(jù)庫文件丟失數(shù)據(jù)恢復(fù)案例

    庫。存儲(chǔ)空間LUN劃分了兩個(gè)邏輯分區(qū)。 服務(wù)器故障&初檢: 由于未知原因,Sql Server數(shù)據(jù)庫文件丟失,丟失數(shù)據(jù)涉及到3個(gè)庫,表的數(shù)量有3000左右。
    的頭像 發(fā)表于 04-11 15:38 ?977次閱讀
    <b class='flag-5'>數(shù)據(jù)</b>庫<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—Sql Server<b class='flag-5'>數(shù)據(jù)庫文件</b><b class='flag-5'>丟失</b>的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例