Skip to main content

Home/ Larvata/ Group items tagged 程序

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
張 旭

第 06 章 - 計算機概論 - 作業系統概論 - 0 views

dic.vbird.tw/...2020unit06.php

system

shared by 張 旭 on 22 Jun 21 - No Cached
  • 自行參考電腦硬體來設計出運算的軟體，當時的系統並沒有『作業系統』的概念，因為應用程式與作業系統是同時設計的。
  • 電腦裡面有儲存設備 (不論是硬碟還是記憶體)， 所以電腦硬體裡面會執行一隻監督程式 (monitor)，使用者可以預先將自己的程式讀進系統，系統先儲存該程式到佇列 (queue)，等到輪到該程式運作後， 就將該程式讀入讓 CPU 開始運作，直到運作結束輸出到印表機之後，將該工作丟棄，然後開始讀入在 queue 裡面的新的程式，依序執行。
  • 將 CPU 與 I/O 分離開
  • ...38 more annotations...
  • 透過卡片與讀卡機，將程式碼一次性的讀進大機器，然後就是等待大機器的運作， 結果再交由印表機印出。如果打卡紙打洞錯誤呢？只好重新打洞，重新排隊去運作程式了。
  • 允許兩個以上的程序在記憶體中等待被 CPU 執行，當 CPU 執行完其中一隻程式後， 第二隻程式就可以立刻被執行，因此效能會比較好。
  • 程序的狀態進入中斷狀態，CPU 不會理會該程序
  • CPU 的排程 (cpu scheduling)
  • 早期單核 CPU 的運作中，CPU 一次只能運作一個工作，因此，若有多個工作要同時進行， 那麼 CPU 就得要安排一個 CPU 運作時間給所有的工作，當該程序達到最大工作時間後，CPU 就會將該工作排回佇列，讓下一隻程序接著運作。
  • 你會覺得 CPU 是同時運作所有的程序，其實不是的！而是 CPU 在各個程序之間切換工作而已。
  • 分時系統其實與多元程式處理系統有點類似， 只是工作的輸入改為透過終端機操作輸入，CPU 可以在各個用戶操作間切換工作，於是每個使用者感覺似乎都是在同步操作電腦系統一般， 這就是分時系統。
  • 早期的程式設計師要設計程式是件苦差事，因為得要了解電腦硬體，並根據該電腦硬體來選擇程式語言，然後根據程式語言來設計運算工作、記憶體讀寫工作、 磁碟與影像輸入輸出工作、檔案存取工作等。等於從硬體、軟體、輸入輸出行為都得要在自己的程式碼裡面一口氣完成才行。
  • 在 1971 年開始的 unix 系統開發後，後續的系統大多使用 unix 的概念
  • 將硬體管理的工作統一交給一組程式碼去進行，而且這組程式碼還提供了一個開發界面
  • 軟體工程師只要依據這組程式碼規範的開發界面後，該軟體開發完成就能夠在這組程式碼上面運作了
  • 程式的執行
  • 作業系統需要將使用者交付的軟體程序分配到記憶體中， 然後透過 CPU 排程持續的交錯的完成各項任務才行。
  • CPU 中斷 (interrupt) 的功能
  • CPU 根據硬體擁有許多與週邊硬體的中斷通道， 當接收到中斷訊號時，CPU 就會嘗試將該程序列入等待的狀態下，讓該硬體自行完成相關的任務後，然後再接管系統。
  • 記憶體管理模組
  • 舊的環境底下，程式設計師需要自己判斷自己的程式會用到多少記憶體，然後自行指定記憶體使用位址的任務。
  • 系統會自動去偵測與管理主記憶體的使用狀態，避免同一個記憶體位址同時被兩個程序所使用而讓程序工作損毀
  • 作業系統核心也在記憶體中， 因此核心也會被這個子系統放入受保護的記憶體區段，一般用戶是無法直接操作該受保護的記憶區段的。
  • 虛擬記憶體 (virtual memory)
  • 主記憶體當中的資料並不是連續的，主記憶體的資料就像磁碟一樣，重複讀、刪、寫之後， 記憶區段是不會連續的
  • CPU 主要讀出虛擬記憶體，記憶體管理模組就會主動讀出資料
  • 一隻程序的資料是連續的 (左側)，但是實際上對應的是在主記憶體或其他位置上
  • CPU 排程
  • 作業系統好不好的重要指標之一！如何讓 CPU 在多工的情況下以最快速的方式將所有的工作完成，這方面的演算法是目前各主要作業系統持續在進步的部份。
  • 磁碟存取與檔案系統
  • 作業系統則需要驅動磁碟(不論是傳統硬碟還是 SSD)，然後也需要了解該磁碟內的檔案系統格式， 之後透過檔案系統這個子系統來進行資料的處理。
  • 裝置的驅動程式
  • 作業系統必須要能夠接受硬體裝置的驅動，所以硬體製造商可以推出給各個不同作業系統使用的驅動程式 (dirver / modules)， 這樣作業系統直接將該驅動程式載入後，即可開始使用該硬體，而不需要重新編譯作業系統。
  • 網路子系統
  • 使用者界面
  • 現代 CPU 設計的主要思考依據，讓一個 CPU 封裝 (單一一顆 CPU 硬體) 裡面，整合多個 CPU 核心，也就是多核心 CPU 製造的思考方向。
  • 對於單執行緒的程式來說， 多核心的 CPU 不見得會跑得比單核的快！這是因為單執行緒只有一個程序在進行，所以 CPU 時脈越高，代表會越快執行完畢。
  • 軟體會將單一工作拆分成數個小工作，分別交給不同的核心去執行，這樣每個核心只要負責一小段任務， 當然 CPU 時脈不用高，只要數量夠大，效能就會提昇很明顯
  • 由於 CPU 是由作業系統控制的，因此，你要使用到多核心的硬體系統，你的作業系統、應用程式都需要設計程可以支援多核心才行！
  • 所謂的平行處理功能，讓一件工作可以拆分成數個部份，讓這些不同的部份丟給不同的 CPU 去運算， 然後再透過一支監控程式，將各別的計算在一定的時間內收回統整後，再次的細分小工作發派出去，持續這些動作後，直到程式執行完畢為止。
  • 對於 Linux 來說，大部分都可以支援到 4096 個 CPU 核心數。
  • 銀行商用大型主機 Unix 系統
張 旭

Asset Pipeline - Ruby on Rails 指南 - 0 views

guides.ruby-china.org/asset_pipeline.html

shared by 張 旭 on 30 Jan 15 - No Cached
  • 清单文件或帮助方法
    • 張 旭
      張 旭 on 30 Jan 15
       
      清單文件是指：application.css 跟 application.js
  • Sprockets 会按照搜索路径中各路径出现的顺序进行搜索。默认情况下，这意味着 app/assets 文件夹中的静态资源优先级较高，会遮盖 lib 和 vendor 文件夹中的相应文件
  • 如果静态资源不会在清单文件中引入，就要添加到预编译的文件列表中，否则在生产环境中就无法访问文件。
  • ...36 more annotations...
  • 程序中使用了 jQuery 代码库和许多模块，都保存在 lib/assets/javascripts/library_name 文件夹中，那么 lib/assets/javascripts/library_name/index.js 文件的作用就是这个代码库的清单。清单文件中可以按顺序列出所需的文件，或者干脆使用 require_tree 指令。
  • 如果使用 Turbolinks（Rails 4 默认启用），加上 data-turbolinks-track 选项后，Turbolinks 会检查静态资源是否有更新，如果更新了就会将其载入页面
  • config.assets.paths 包含标准路径和其他 Rails 引擎添加的路径。
  • 链接不存在的资源（也包括链接到空字符串的情况）会在调用页面抛出异常。
  • 关闭标签不能使用 -%> 形式
  • Sprockets 通过清单文件决定要引入和伺服哪些静态资源
  • 在 JavaScript 文件中，Sprockets 的指令以 //= 开头。在上面的文件中，用到了 require 和 the require_tree 指令。
  • app/assets/javascripts/application.js
  • require_tree 指令告知 Sprockets 递归引入指定文件夹中的所有 JavaScript 文件。文件夹的路径必须相对于清单文件。也可使用 require_directory 指令加载指定文件夹中的所有 JavaScript 文件，但不会递归。
  • Sprockets 会按照从上至下的顺序处理指令，但 require_tree 引入的文件顺序是不可预期的，不要设想能得到一个期望的顺序。
  • app/assets/stylesheets/application.css
  • 不管创建新程序时有没有指定 --skip-sprockets 选项，Rails 4 都会生成 app/assets/javascripts/application.js 和 app/assets/stylesheets/application.css
  • 如果多次调用 require_self，只有最后一次调用有效
  • 如果想使用多个 Sass 文件，应该使用 Sass 中的 @import 规则，不要使用 Sprockets 指令。
  • 清单文件可以有多个。
  • 如果使用默认的 gem，生成控制器或脚手架时，会生成 CoffeeScript 和 SCSS 文件，而不是普通的 JavaScript 和 CSS 文件。
  • 在开发环境中，或者禁用 Asset Pipeline 时，这些文件会使用 coffee-script 和 sass 提供的预处理器处理，然后再发给浏览器
  • 启用 Asset Pipeline 时，这些文件会先使用预处理器处理，然后保存到 public/assets 文件夹中，再由 Rails 程序或网页服务器伺服
  • 添加额外的扩展名可以增加预处理次数，预处理程序会按照扩展名从右至左的顺序处理文件内容。所以，扩展名的顺序要和处理的顺序一致
  • 预处理器的执行顺序很重要
  • 在开发环境中也可启用压缩功能，检查是否能正常运行。需要调试时再禁用压缩即可。
  • 默认情况下，Rails 认为静态资源已经事先编译好了，直接由网页服务器伺服。
  • 般情况下，请勿修改 config.assets.digest 的默认值
  • 可在部署时编译静态资源
  • 在多次部署之间共用这个文件夹是十分重要的，这样只要缓存的页面可用，其中引用的编译后的静态资源就能正常使用。
  • 默认编译的文件包括 application.js、application.css 以及 gem 中 app/assets 文件夹中的所有非 JS/CSS 文件（会自动加载所有图片）
  • 如果想编译其他清单，或者单独的样式表和 JavaScript，可以添加到 config/application.rb 文件中的 precompile 选项
  • 设置编译所有静态资源
  • manifest-md5hash.json 的文件，列出所有静态资源和对应的指纹
  • 把 Expires 报头设置为很久以后
  • 在本地预编译后，可以把编译好的文件纳入版本控制系统，再按照常规的方式部署
  • 实时编译消耗的内存更多，比默认的编译方式性能更低，因此不推荐使用
  • 如果用 CDN 分发静态资源，要确保文件不会被缓存，因为缓存会导致问题。如果设置了 config.action_controller.perform_caching = true，Rack::Cache 会使用 Rails.cache 存储静态文件，很快缓存空间就会用完。
  • Sprockets 默认使用的公开路径是 /assets
  • X-Sendfile 报头的作用是让服务器忽略程序的响应，直接从硬盘上伺服指定的文件
  • 为 Rails 提供标准 JavaScript 代码库的 jquery-rails gem 是个很好的例子。这个 gem 中有个引擎类，继承自 Rails::Engine。添加这层继承关系后，Rails 就知道这个 gem 中可能包含静态资源文件，会把这个引擎中的 app/assets、lib/assets 和 vendor/assets 三个文件夹加入 Sprockets 的搜索路径中。
張 旭

单表60亿记录等大数据场景的MySQL优化和运维之道 - 快课网 - 0 views

www.cricode.com/3981.html

mysql system performance HA database

shared by 張 旭 on 18 Nov 15 - No Cached
  • 存储引擎使用InnoDB
  • 变长字符串尽量使用varchar varbinary
  • 不在数据库中存储图片、文件等
  • ...34 more annotations...
  • 库名、表名、字段名、索引名使用小写字母，以下划线分割 ，需要见名知意
  • 所有字段均定义为NOT NULL ，除非你真的想存Null
  • 使用TIMESTAMP存储时间
  • 使用DECIMAL存储精确浮点数，用float有的时候会有问题
  • 单个索引字段数不超过5，单表索引数量不超过5，索引设计遵循B+ Tree索引最左前缀匹配原则
  • 建立的索引能覆盖80%主要的查询，不求全，解决问题的主要矛盾
  • 避免冗余索引
  • 索引这个东西是一把双刃剑，在加速读的同时也引入了很多额外的写入和锁，降低写入能力
  • 字段定义为varchar，但传入的值是个int，就会导致全表扫描，要求程序端要做好类型检查
  • 避免使用大表的JOIN，MySQL优化器对join优化策略过于简单
  • UPDATE、DELETE语句不使用LIMIT ，容易造成主从不一致
  • 高危操作检查，Drop前做好数据备份
  • 日志分析，主要是指的MySQL慢日志和错误日志
  • Percona公司根据Facebook OSC思路，用perl重写了一版，就是我们现在用得很多的pt-online-schema-change，软件本身非常成熟，支持目前主流版本
  • 原生主从同步肯定存在着性能和安全性问题
  • Sharding is very complex, so itʼs best not to shard until itʼs obvious that you will actually need to!
  • 有中间层控制拆分逻辑最好，否则拆分过细管理成本会很高
  • 全量binlog备份
  • xtrabackup热备
  • 采用分布式文件系统存储备份
  • 基于库级别的复制，所以如果你只有一个库，使用这个意义不大
  • 半同步复制，从5.5开始支持
  • 半同步通过从库返回ACK这种方式确认从库收到数据
  • Secondsbehindmaster来判断延时不可靠，在网络抖动或者一些特殊参数配置情况下，会造成这个值是0但其实延时很大了。通过heartbeat表插入时间戳这种机制判断延时是更靠谱的
  • Binlog格式，建议都采用row格式，数据一致性更好
  • 成熟开源事务存储引擎，支持ACID，支持事务四个隔离级别，更好的数据安全性，高性能高并发，MVCC，细粒度锁，支持O_DIRECT
  • 数据安全性至关重要，InnoDB完胜
  • 主流使用TokuDB主要是看中了它的高压缩比
  • TokuDB在测试过程中写入稳定性是非常好的
  • 单表容量在InnoDB下1TB+，使用Tokudb的lzma压缩到80GB
  • 独立写程序好一些，与程序解耦方便后期维护
  • 追踪字段值变化可以通过分析row格式binlog好一些
  • 解决了单表过大恢复时间问题，也支持online DDL
  • 物理备份采用xtrabackup热备方案比较好
張 旭

鳥哥的 Linux 私房菜 -- 第零章、計算機概論 - 0 views

linux.vbird.org/...0105computers.php

system

shared by 張 旭 on 22 Jun 21 - No Cached
  • 但因為 CPU 的運算速度比其他的設備都要來的快，又為了要滿足 FSB 的頻率，因此廠商就在 CPU 內部再進行加速， 於是就有所謂的外頻與倍頻了。
  • 中央處理器 (Central Processing Unit, CPU)，CPU 為一個具有特定功能的晶片， 裡頭含有微指令集，如果你想要讓主機進行什麼特異的功能，就得要參考這顆 CPU 是否有相關內建的微指令集才可以。
  • CPU 內又可分為兩個主要的單元，分別是： 算數邏輯單元與控制單元。
  • ...63 more annotations...
  • CPU 讀取的資料都是從主記憶體來的！ 主記憶體內的資料則是從輸入單元所傳輸進來！而 CPU 處理完畢的資料也必須要先寫回主記憶體中，最後資料才從主記憶體傳輸到輸出單元。
  • 重點在於 CPU 與主記憶體。 特別要看的是實線部分的傳輸方向，基本上資料都是流經過主記憶體再轉出去的！
  • CPU 實際要處理的資料則完全來自於主記憶體 (不管是程式還是一般文件資料)！這是個很重要的概念喔！ 這也是為什麼當你的記憶體不足時，系統的效能就很糟糕！
  • 常見到的兩種主要 CPU 架構， 分別是：精簡指令集 (RISC) 與複雜指令集 (CISC) 系統。
  • 微指令集較為精簡，每個指令的執行時間都很短，完成的動作也很單純，指令的執行效能較佳； 但是若要做複雜的事情，就要由多個指令來完成。
  • CISC在微指令集的每個小指令可以執行一些較低階的硬體操作，指令數目多而且複雜， 每條指令的長度並不相同。因為指令執行較為複雜所以每條指令花費的時間較長， 但每條個別指令可以處理的工作較為豐富。
  • 多媒體微指令集：MMX, SSE, SSE2, SSE3, SSE4, AMD-3DNow! 虛擬化微指令集：Intel-VT, AMD-SVM 省電功能：Intel-SpeedStep, AMD-PowerNow! 64/32位元相容技術：AMD-AMD64, Intel-EM64T
  • 若光以效能來說，目前的個人電腦效能已經夠快了，甚至已經比工作站等級以上的電腦運算速度還要快！ 但是工作站電腦強調的是穩定不當機，並且運算過程要完全正確，因此工作站以上等級的電腦在設計時的考量與個人電腦並不相同啦
  • 1 Byte = 8 bits
  • 檔案容量使用的是二進位的方式，所以 1 GBytes 的檔案大小實際上為：1024x1024x1024 Bytes 這麼大！ 速度單位則常使用十進位，例如 1GHz 就是 1000x1000x1000 Hz 的意思。
  • CPU的運算速度常使用 MHz 或者是 GHz 之類的單位，這個 Hz 其實就是秒分之一
  • 在網路傳輸方面，由於網路使用的是 bit 為單位，因此網路常使用的單位為 Mbps 是 Mbits per second，亦即是每秒多少 Mbit
  • (1)北橋：負責連結速度較快的CPU、主記憶體與顯示卡界面等元件
  • (2)南橋：負責連接速度較慢的裝置介面， 包括硬碟、USB、網路卡等等
  • CPU內部含有微指令集，不同的微指令集會導致CPU工作效率的優劣
  • 時脈就是CPU每秒鐘可以進行的工作次數。 所以時脈越高表示這顆CPU單位時間內可以作更多的事情。
  • 早期的 CPU 架構主要透過北橋來連結系統最重要的 CPU、主記憶體與顯示卡裝置。因為所有的設備都得掉透過北橋來連結，因此每個設備的工作頻率應該要相同。
  • 前端匯流排 (FSB)
  • 外頻指的是CPU與外部元件進行資料傳輸時的速度
  • 倍頻則是 CPU 內部用來加速工作效能的一個倍數
  • 新的 CPU 設計中， 已經將記憶體控制器整合到 CPU 內部，而連結 CPU 與記憶體、顯示卡的控制器的設計，在Intel部份使用 QPI (Quick Path Interconnect) 與 DMI 技術，而 AMD 部份則使用 Hyper Transport 了，這些技術都可以讓 CPU 直接與主記憶體、顯示卡等設備分別進行溝通，而不需要透過外部的連結晶片了。
  • 如何知道主記憶體能提供的資料量呢？此時還是得要藉由 CPU 內的記憶體控制晶片與主記憶體間的傳輸速度『前端匯流排速度(Front Side Bus, FSB)
  • 主記憶體也是有其工作的時脈，這個時脈限制還是來自於 CPU 內的記憶體控制器所決定的。
  • CPU每次能夠處理的資料量稱為字組大小(word size)， 字組大小依據CPU的設計而有32位元與64位元。我們現在所稱的電腦是32或64位元主要是依據這個 CPU解析的字組大小而來的
  • 早期的32位元CPU中，因為CPU每次能夠解析的資料量有限， 因此由主記憶體傳來的資料量就有所限制了。這也導致32位元的CPU最多只能支援最大到4GBytes的記憶體。
  • 在每一個 CPU 內部將重要的暫存器 (register) 分成兩群， 而讓程序分別使用這兩群暫存器。
  • 可以有兩個程序『同時競爭 CPU 的運算單元』，而非透過作業系統的多工切換！
  • 大多發現 HT 雖然可以提昇效能，不過，有些情況下卻可能導致效能降低喔！因為，實際上明明就僅有一個運算單元
  • 個人電腦的主記憶體主要元件為動態隨機存取記憶體(Dynamic Random Access Memory, DRAM)， 隨機存取記憶體只有在通電時才能記錄與使用，斷電後資料就消失了。因此我們也稱這種RAM為揮發性記憶體。
  • 要啟用雙通道的功能你必須要安插兩支(或四支)主記憶體，這兩支記憶體最好連型號都一模一樣比較好， 這是因為啟動雙通道記憶體功能時，資料是同步寫入/讀出這一對主記憶體中，如此才能夠提升整體的頻寬啊！
  • 第二層快取(L2 cache)整合到CPU內部，因此這個L2記憶體的速度必須要CPU時脈相同。 使用DRAM是無法達到這個時脈速度的，此時就需要靜態隨機存取記憶體(Static Random Access Memory, SRAM)的幫忙了。
  • BIOS(Basic Input Output System)是一套程式，這套程式是寫死到主機板上面的一個記憶體晶片中， 這個記憶體晶片在沒有通電時也能夠將資料記錄下來，那就是唯讀記憶體(Read Only Memory, ROM)。
  • BIOS對於個人電腦來說是非常重要的， 因為他是系統在開機的時候首先會去讀取的一個小程式
  • 由於磁碟盤是圓的，並且透過機器手臂去讀寫資料，磁碟盤要轉動才能夠讓機器手臂讀寫。因此，通常資料寫入當然就是以圓圈轉圈的方式讀寫囉！ 所以，當初設計就是在類似磁碟盤同心圓上面切出一個一個的小區塊，這些小區塊整合成一個圓形，讓機器手臂上的讀寫頭去存取。 這個小區塊就是磁碟的最小物理儲存單位，稱之為磁區 (sector)，那同一個同心圓的磁區組合成的圓就是所謂的磁軌(track)。 由於磁碟裡面可能會有多個磁碟盤，因此在所有磁碟盤上面的同一個磁軌可以組合成所謂的磁柱 (cylinder)。
  • 原本硬碟的磁區都是設計成 512byte 的容量，但因為近期以來硬碟的容量越來越大，為了減少資料量的拆解，所以新的高容量硬碟已經有 4Kbyte 的磁區設計
  • 拿快閃記憶體去製作成高容量的設備，這些設備的連接界面也是透過 SATA 或 SAS，而且外型還做的跟傳統磁碟一樣
  • 固態硬碟最大的好處是，它沒有馬達不需要轉動，而是透過記憶體直接讀寫的特性，因此除了沒資料延遲且快速之外，還很省電
  • 硬碟主要是利用主軸馬達轉動磁碟盤來存取，因此轉速的快慢會影響到效能
  • 使用作業系統的正常關機方式，才能夠有比較好的硬碟保養啊！因為他會讓硬碟的機械手臂歸回原位啊！
  • I/O位址有點類似每個裝置的門牌號碼，每個裝置都有他自己的位址，一般來說，不能有兩個裝置使用同一個I/O位址， 否則系統就會不曉得該如何運作這兩個裝置了。
  • IRQ就可以想成是各個門牌連接到郵件中心(CPU)的專門路徑囉！ 各裝置可以透過IRQ中斷通道來告知CPU該裝置的工作情況，以方便CPU進行工作分配的任務。
  • BIOS為寫入到主機板上某一塊 flash 或 EEPROM 的程式，他可以在開機的時候執行，以載入CMOS當中的參數， 並嘗試呼叫儲存裝置中的開機程式，進一步進入作業系統當中。
  • 電腦都只有記錄0/1而已，甚至記錄的資料都是使用byte/bit等單位來記錄的
  • 常用的英文編碼表為ASCII系統，這個編碼系統中， 每個符號(英文、數字或符號等)都會佔用1bytes的記錄， 因此總共會有28=256種變化
  • 中文字當中的編碼系統早期最常用的就是big5這個編碼表了。 每個中文字會佔用2bytes，理論上最多可以有216=65536，亦即最多可達6萬多個中文字。
  • 國際組織ISO/IEC跳出來制訂了所謂的Unicode編碼系統， 我們常常稱呼的UTF8或萬國碼的編碼
  • CPU其實是具有微指令集的。因此，我們需要CPU幫忙工作時，就得要參考微指令集的內容， 然後撰寫讓CPU讀的懂的指令碼給CPU執行，這樣就能夠讓CPU運作了。
  • 編譯器』來將這些人類能夠寫的程式語言轉譯成為機器能看懂得機器碼
  • 當你需要將運作的資料寫入記憶體中，你就得要自行分配一個記憶體區塊出來讓自己的資料能夠填上去， 所以你還得要瞭解到記憶體的位址是如何定位的，啊！眼淚還是不知不覺的流了下來... 怎麼寫程式這麼麻煩啊！
  • 作業系統(Operating System, OS)其實也是一組程式， 這組程式的重點在於管理電腦的所有活動以及驅動系統中的所有硬體。
  • 作業系統的功能就是讓CPU可以開始判斷邏輯與運算數值、 讓主記憶體可以開始載入/讀出資料與程式碼、讓硬碟可以開始被存取、讓網路卡可以開始傳輸資料、 讓所有周邊可以開始運轉等等。
  • 只有核心有提供的功能，你的電腦系統才能幫你完成！舉例來說，你的核心並不支援TCP/IP的網路協定， 那麼無論你購買了什麼樣的網卡，這個核心都無法提供網路能力的！
  • 核心程式所放置到記憶體當中的區塊是受保護的！ 並且開機後就一直常駐在記憶體當中。
  • 作業系統通常會提供一整組的開發介面給工程師來開發軟體！ 工程師只要遵守該開發介面那就很容易開發軟體了！
  • 系統呼叫介面(System call interface)
  • 程序管理(Process control)
  • 記憶體管理(Memory management)
  • 檔案系統管理(Filesystem management)
  • 通常核心會提供虛擬記憶體的功能，當記憶體不足時可以提供記憶體置換(swap)的功能
  • 裝置的驅動(Device drivers)
  • 『可載入模組』功能，可以將驅動程式編輯成模組，就不需要重新的編譯核心
  • 驅動程式可以說是作業系統裡面相當重要的一環
  • 作業系統通常會提供一個開發介面給硬體開發商， 讓他們可以根據這個介面設計可以驅動他們硬體的『驅動程式』，如此一來，只要使用者安裝驅動程式後， 自然就可以在他們的作業系統上面驅動這塊顯示卡了。
  • 張 旭 on 22 Jun 21
     
    "但因為 CPU 的運算速度比其他的設備都要來的快，又為了要滿足 FSB 的頻率，因此廠商就在 CPU 內部再進行加速， 於是就有所謂的外頻與倍頻了。"
張 旭

从达标到卓越 -- API 设计之道 | Taobao FED | 淘宝前端团队 - 0 views

taobaofed.org/...index.html

api system development programming taobao

shared by 張 旭 on 21 Feb 17 - No Cached
  • 高级语言和自然语言（英语）其实相差无几，因此正确地使用（英语的）词法和语法是程序员最基本的素养。
  • 只要能够足够接近人类的日常语言和思维，并且不需要引发额外的大脑思考，那就是易用
  • 词法和语法
  • ...53 more annotations...
  • 语义
  • 版本控制
  • 正确地拼写一个单词是底线
  • 认真地注意 IDE 的 typo 提示（单词拼写错误提示）
  • state 是整个 Component 状态机中的某一个特定状态，既然描述为了状态机，那么状态和状态之间是互相切换的关系。所以对于初始状态，用 initial 来修饰。
  • props 是指 Element 的属性，要么是不存在某个属性值后来为它赋值，要么是存在属性的默认值后来将其覆盖。所以这种行为，default 是合理的修饰词。
  • 成对出现的词应该是：show & hide、open & close。
  • 成对出现的正反义词不可混用
  • 在复数的风格上保持一致，要么所有都是 -s，要么所有都是 -list。
  • 涉及到诸如字典（Dictionary）、表（Map）的时候，不要使用复数！
  • 「map」本身已经包含了这层意思，不需要再用复数去修饰它
  • 最好遵从惯例，使用名词组合 success 和 failure
  • 方法命名用动词
  • 属性命名用名词
  • 布尔值类型用形容词
  • 首字母缩写词的所有字母均大写。（如果某个语言环境有明确的业界惯例，则遵循惯例。）
  • 如果什么都没定，也没业界惯例，那么把单词写全了总是不会错的。
  • React 采用了 componentDidMount 这种过去时风格，而没有使用 componentMounted，从而跟 componentWillMount 形成对照组，方便记忆。
  • 尽量避免使用被动语态。因为被动语态看起来会比较绕，不够直观，因此我们要将被动语态的 API 转换为主动语态。
  • 无论是友好的参数设置，还是让人甜蜜蜜的语法糖，都体现了程序员的人文关怀。
  • 在文件（file）层面同样如此，一个文件只编写一个类，保证文件的职责单一（当然这对很多语言来说是天然的规则）。
  • 将混杂在一个大坨函数中的两件独立事情拆分出去，保证函数（function）级别的职责单一。
  • 现实中的 OOP 编程场景难免触及副作用。
  • 函数本身的运行稳定可预期
  • 函数的运行不对外部环境造成意料外的污染
  • SPM 是阿里通用的埋点统计方案
  • 对外部造成污染一般是两种途径：一是在函数体内部直接修改外部作用域的变量，甚至全局变量；二是通过修改实参间接影响到外部环境，如果实参是引用类型的数据结构。
  • 控制读写权限
  • 优化参数顺序。相关性越高的参数越要前置
  • 可省略的参数后置，以及 为可省略的参数设定缺省值
  • 将可省参数后置同样是最佳实践。
  • 重载（overload）
  • 如果入口参数无法进行有效区分，不要选择重载
  • 根本不明白某个 Boolean 标记位是用来干嘛的，这大大降低了用户的开发体验，以及代码可读性。
    • 張 旭
      張 旭 on 21 Feb 17
       
      我在 ADATA 的 message saver 犯了一樣的錯誤。
  • 同时支持单个和批量的处理，可以降低用户的认知负担。
  • 让 setter 型 API 始终返回 this。这是 jQuery 为我们带来的经典启示 —— 通过返回 this，来产生一种「链式调用（chaining）」的风格
  • 对异步操作都返回一个 Promise
  • 对于一些创造出来的、业务特色的词汇，如果不能用英语简明地翻译，就直接用拼音
  • 一致性可以最大程度降低信息熵
  • 打 log 要么都用中文，要么都用英文。
  • 所有的 setter 操作必须返回 this
  • 「大版本号」即「语义化版本命名」<major>.<minor>.<patch> 中的第一位 <major> 位
  • 接口的扩展方式有很多，比如：继承（extend）、组合（mixin）、装饰（decorate）
  • 在逻辑上确实存在派生关系，并且需要沿用基类行为同时自定义行为的，采用重量级的继承
  • 仅仅是扩充一些行为功能，但是逻辑上压根不存在父子关系的，使用组合
  • 装饰手法更多应用于给定一个接口，将其包装成多种适用于不同场景新接口的情况
  • $.fn.customMethod = function() {};
  • 合理的做法是新增一个 subType 字段
  • 抽象级别一般来说越高越好，将 API 设计成业务无关的，更通用，而且方便扩展
  • 利用多态性（Polymorphism）构建 Consistent APIs。
  • 作为 API 的开发者，一定要提供足够场景适用的 API，来引导我们的用户，不要让他们做出一些出人意料的「妙用」之举
  • 写代码，就像写作，而设计 API 好比列提纲。
  • Think about future, design with flexibility, but only implement for production.
張 旭

Code Review: 超越 "审、查、评" 的代码回顾 » 社區 » Coding Style - 0 views

www.codingstyle.cn/35

code programming team

shared by 張 旭 on 28 Dec 15 - No Cached
  • 在相互挑错的场合里，人的内心会本能地封闭起来，来抗拒那些针对自己的批评意见。相互挑错所造成的紧张气氛，会让程序员对Code Review望而却步，从而情绪低落，这会让Code Review的效果大打折扣。
  • 把Code Review称为“代码回顾”好一些。如果大家放弃“挑错”，来“共同学习”
  • 团队成员共同识别模式
  • ...10 more annotations...
  • 程序员编写代码的习惯
  • 几百行的一个类文件
  • 复杂的if-else嵌套
  • 代码回顾的过程中，完全可以不提谁是代码的作者，而只提“好模式”和“反模式”，这样能让作者放松心态
  • 好模式和反模式，其实就是编程的好习惯和坏习惯。代码回顾应该重在识别编程习惯，而不是找bug
  • 代码回顾也需要每次少量，每日持续
  • 将每日代码回顾的时间控制在半小时以内，细水长流，才能持续
  • 每日的代码回顾，仅需要在半小时内，大家一起看200～300行随机抽取的当天编写的代码就够了
  • 如果代码编写得好，那么不是作者的人就能在没有作者帮助的情况下读懂。我希望一位不是这段代码作者的志愿者，来为大家解释一下这段代码是做什么的。
  • 要尽量找那些被改正过来的曾经的反模式，比如“这段代码用到了方法提取，且命名富有表达力，改掉了昨天’长方法’的反模式”。只识别反模式，不识别好模式，会让代码回顾退化到令人生畏的代码审查，打掉大家长期坚持的积极性。
張 旭

第 05 章 - 計算機概論 - 主機系統與 I/O 界面 - 0 views

dic.vbird.tw/...2020unit05.php

shared by 張 旭 on 21 Jun 21 - No Cached
  • 接受使用者輸入指令與資料，經由中央處理器的數學與邏輯單元運算處理後，以產生或儲存成有用的資訊
  • CPU 為一個具有特定功能的晶片， 裡頭含有微指令集，如果你想要讓主機進行什麼特異的功能，就得要參考這顆 CPU 是否有相關內建的微指令集才可以。
  • CPU 讀取的資料都是從主記憶體來的！ 主記憶體內的資料則是從輸入單元所傳輸進來！而 CPU 處理完畢的資料也必須要先寫回主記憶體中，最後資料才從主記憶體傳輸到輸出單元。
  • ...49 more annotations...
  • 算數邏輯單元與控制單元。其中算數邏輯單元主要負責程式運算與邏輯判斷，控制單元則主要在協調各周邊元件與各單元間的工作。
  • 資料會先寫入到主記憶體，然後 CPU 才能開始應用
  • CPU 其實內部已經含有一些微指令，我們所使用的軟體都要經過 CPU 內部的微指令集來達成才行。
  • 世界上常見到的兩種主要 CPU 架構， 分別是：精簡指令集 (RISC) 與複雜指令集 (CISC) 系統。
  • 微指令集較為精簡，每個指令的執行時間都很短，完成的動作也很單純，指令的執行效能較佳； 但是若要做複雜的事情，就要由多個指令來完成。
  • CISC在微指令集的每個小指令可以執行一些較低階的硬體操作，指令數目多而且複雜， 每條指令的長度並不相同。因為指令執行較為複雜所以每條指令花費的時間較長， 但每條個別指令可以處理的工作較為豐富。
  • 最早的那顆Intel發展出來的CPU代號稱為8086
  • AMD依此架構修改新一代的CPU為64位元
  • CPU 位元指的是CPU一次資料讀取的最大量！64位元CPU代表CPU一次可以讀寫64bits這麼多的資料
  • 因為CPU讀取資料量有限制，因此能夠從記憶體中讀寫的資料也就有所限制
  • ：(1)北橋：負責連結速度較快的CPU、主記憶體與顯示卡界面等元件；
  • (2)南橋：負責連接速度較慢的裝置介面， 包括硬碟、USB、網路卡等等。不過由於北橋最重要的就是 CPU 與主記憶體之間的橋接，因此目前的主流架構中， 大多將北橋記憶體控制器整合到 CPU 封裝當中
  • CPU 與可接受的晶片組是有搭配性的，尤其目前每種 CPU 的腳位都不一樣
  • 時脈越高，代表單位時間內可進行的工作越多
  • 大概都只看總頻寬或基準時脈
  • CPU 時脈越高的情況下，會產生很多諸如散熱、設計及與週邊元件溝通的問題。
  • 其他的程序還在等待 CPU ，但是 CPU 又在等待 I/O
  • Intel 在同一個運算核心底下安裝兩個暫存器來模擬出另一個核心，實際上是兩個暫存器 (可以想成是程式的執行器) 共用一個實體核心。 這就是超執行緒的簡易認知
  • 時脈的意思是每秒鐘能夠進行的工作次數，而每次工作能夠讀進的資料量就是位元數
  • 每個用戶端大多是短時間的大運算，所以通常不會有一隻程序一直佔用著系統資源。
  • CPU 的所有資料都是從記憶體讀寫來的，所以記憶體的容量與頻寬就相當的重要了
  • DRAM 根據技術的更新又分好幾代，而使用上較廣泛的有所謂的 SDRAM 與 DDR SDRAM 兩種。 這兩種記憶體的差別除了在於腳位與工作電壓上的不同之外，DDR 是所謂的雙倍資料傳送速度 (Double Data Rate)
  • 晶片組廠商就將兩個主記憶體彙整在一起，如果一支記憶體可達 64 位元，兩支記憶體就可以達到 128 位元了，這就是雙通道的設計理念。 在某些比較多核心的伺服器主機上面，甚至還使用了 3 通道到 4 通道的設計
  • CPU 內部的暫存器與少量記憶體被稱為第一、第二層快取 (L1, L2 cache)，而放在核心間的快取記憶體就被稱為第三層快取記憶體 (L3 cache)
  • CPU 的暫存器是直接設計在 CPU 核心內部，可以用來幫助 CPU 的運算。
  • 在多核心 CPU 的核心之間，會有另一個共享的快取記憶體存在，讓所有的 CPU 核心可以共享某些資源。
  • 靜態隨機存取記憶體 (Static Random Access Memory, SRAM)
  • 各項參數， 是被記錄到主機板上頭的一個稱為 CMOS 的晶片上，這個晶片需要藉著額外的電源來發揮記錄功能， 這也是為什麼你的主機板上面會有一顆電池的緣故。
  • BIOS(Basic Input Output System)是一套程式，這套程式是寫死到主機板上面的一個記憶體晶片中， 這個記憶體晶片在沒有通電時也能夠將資料記錄下來，那就是唯讀記憶體(Read Only Memory, ROM)。
  • BIOS對於個人電腦來說是非常重要的， 因為他是系統在開機的時候首先會去讀取的一個小程式喔
  • 韌體(firmware)很多也是使用ROM來進行軟體的寫入的。 韌體像軟體一樣也是一個被電腦所執行的程式，然而他是對於硬體內部而言更加重要的部分。例如BIOS就是一個韌體， BIOS雖然對於我們日常操作電腦系統沒有什麼太大的關係，但是他卻控制著開機時各項硬體參數的取得！
  • 現在的 BIOS 通常是寫入類似快閃記憶體 (flash) 或 EEPROM
  • 顯示卡能夠傳輸的資料量當然也是越大越好！這時就得要考慮到傳輸的界面了！當前 (2018) 主流的傳輸界面為 PCI-E，這個 PCI-E 又有三種版本， version 1, 2, 3 ，這三個版本的速度並不相同
  • PCI-E (PCI-Express) 使用的是類似管線的概念來處理，在 PCI-E 第一版中，每條管線可以具有 250MBytes/s 的頻寬效能，管線越多(通常設計到 x16 管線)則總頻寬越高
  • 通常 CPU 製造商會根據 CPU 來設計搭配的南橋晶片，由於現在只有一個晶片 (北橋整合到 CPU 內了)，所以目前只有一顆主機板晶片組。
  • 插槽上面的資料要傳輸到 CPU 就得要經過晶片組，然後透過 DMI 通道傳上去！所以，在某些情況下，系統的效能會被卡住在這條通道上喔！
  • 晶片組接的設備相當多喔！有 PCI-E 插槽、USB設備、網路設備、音效設備、硬碟設備等，這全部的裝置共用那一條 DMI 喔！ 所以，整個系統效能的瓶頸通常不在 CPU 啦！通常就是在南橋接的設備上面！所以，當你有非常複雜的程式要運作的時候，讓這些程式越少通過南橋， 他的系統效能就會比較好一點
  • 物理組成
  • 讀寫主要是透過在機械手臂上的讀取頭(head)來達成
  • 由於磁碟盤是圓的，並且透過機器手臂去讀寫資料，磁碟盤要轉動才能夠讓機器手臂讀寫。
  • 磁碟的最小物理儲存單位，稱之為磁區 (sector)，那同一個同心圓的磁區組合成的圓就是所謂的磁軌(track)。 由於磁碟裡面可能會有多個磁碟盤，因此在所有磁碟盤上面的同一個磁軌可以組合成所謂的磁柱 (cylinder)。
  • 通常資料的讀寫會由外圈開始往內寫
  • 目前主流的硬碟連接界面就是 SATA
  • 雖然 SATA III 界面理論傳輸可到達 600Mbytes/s，不過傳統硬碟由於物理設計的限制因素，通常存取速度效能大多在 150~200Mbytes/s 之間
  • 串列式 SCSI (Serial Attached SCSI, SAS)
  • 傳統硬碟有個很致命的問題，就是需要驅動馬達去轉動磁碟盤～這會造成很嚴重的磁碟讀取延遲
  • 快閃記憶體去製作成高容量的設備
  • 沒有讀寫頭與磁碟盤啊！都是記憶體！
  • 各個繪圖卡的運算晶片 (GPU) 設計的理念不同，加上驅動程式與軟體搭配的問題，並不是一張高效能繪圖卡就可以完勝其他的繪圖卡， 還得要注意相關的軟體才行。
張 旭

Kubernetes 基本概念 · Kubernetes指南 - 0 views

feisky.gitbooks.io/...concepts.html

kubernetes volume namespace system devops

shared by 張 旭 on 30 May 19 - No Cached
  • Container（容器）是一种便携式、轻量级的操作系统级虚拟化技术。它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。
  • 每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。+
  • Pod 是一组紧密关联的容器集合，它们共享 PID、IPC、Network 和 UTS namespace，是 Kubernetes 调度的基本单位。
  • ...9 more annotations...
  • 进程间通信和文件共享
  • 在 Kubernetes 中，所有对象都使用 manifest（yaml 或 json）来定义
  • Node 是 Pod 真正运行的主机，可以是物理机，也可以是虚拟机。
  • 每个 Node 节点上至少要运行 container runtime（比如 docker 或者 rkt）、kubelet 和 kube-proxy 服务。
  • 常见的 pods, services, replication controllers 和 deployments 等都是属于某一个 namespace 的（默认是 default）
  • node, persistentVolumes 等则不属于任何 namespace
  • Service 是应用服务的抽象，通过 labels 为应用提供负载均衡和服务发现。
  • 匹配 labels 的 Pod IP 和端口列表组成 endpoints，由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
  • 每个 Service 都会自动分配一个 cluster IP（仅在集群内部可访问的虚拟地址）和 DNS 名
  • 張 旭 on 30 May 19
     
    "常见的 pods, services, replication controllers 和 deployments 等都是属于某一个 namespace 的（默认是 default），而 node, persistentVolumes 等则不属于任何 namespace。"
張 旭

CGI、FastCGI和PHPFPM关系图解 - 歪麦博客 - 1 views

www.awaimai.com/371.html

web server CGI

shared by 張 旭 on 30 Dec 16 - No Cached
  • Web Server（如Apache）只是内容的分发者
  • Web Server 一般指Apache、Nginx、IIS、Lighttpd、Tomcat等服务器
  • Web Application 一般指PHP、Java、Asp.net等应用程序
  • ...1 more annotation...
  • Apache/Nginx + FastCGI + PHP-FPM(+PHP-CGI)
張 旭

一位开发者的 Linux 容器之旅 - 51CTO.COM - 0 views

developer.51cto.com/...497798.htm

docker linux container system development devops

shared by 張 旭 on 22 Nov 15 - No Cached
  • 容器是一个 Linux 进程，Linux 认为它只是一个运行中的进程。该进程只知道它被告知的东西。
  • 容器进程也分配了它自己的 IP 地址
  • 操作系统被所有容器所共享，减少了容器足迹的重复和冗余。每个容器只包括该容器特有的部分
  • ...26 more annotations...
  • 可以在容器管理器上运行命令，使容器 IP 映射到主机中能访问公网的 IP 地址。建立了该映射，无论出于什么意图和目的，容器就是网络上一个可访问的独立机器，从概念上类似于虚拟机。
  • 容器是拥有不同 IP 地址从而使其成为网络上可识别的独立 Linux 进程
  • 容器/进程以动态、合作的方式共享主机上的资源。
  • 容器能非常快速地启动
  • 和典型虚拟机的静态方式不同。所有这些资源的共享都由容器管理器来管理。
  • 获得了虚拟机独立和封装的好处，而抛弃了静态资源专有的缺陷
  • 托管容器的计算机运行着被剥离的只剩下主要部分的某个 Linux 版本
  • Ubuntu Snappy
  • Red Hat Atomic Host
  • CoreOS
  • 在容器化方面，容器进程有它自己的 IP 地址。一旦给予了一个 IP 地址，该进程就是宿主网络中可识别的资源
  • 一个容器组件被称为层（layer）
  • 层是一个容器镜像
  • 容器管理器只提供你所要的操作系统在宿主操作系统中不存在的部分
  • 在容器配置文件中重新定义层
  • 容器的各种功能都由一个称为容器管理器（container manager）的软件控制
  • Docker
  • Rocket
  • 镜像存储在注册库（registry）中，注册库通过网络访问
  • 注册库类似于一个使用 Java 的人眼中的 Maven 仓库、使用 .NET 的人眼中的 NuGet 服务器。
  • 容器管理器会封装你应用程序的所有东西为一个独立容器，该容器将会在容器管理器的管理下运行在宿主计算机上。
  • 每个容器有一个独立的 IP 地址
  • 在一个负载均衡容器后运行容器集群以获得更高的性能和高可用计算
  • Deis 的容器配置技术
  • 每次添加实例到环境中时，你不需要手动配置负载均衡器以便接受你的容器镜像。
  • 使用服务发现技术让容器告知均衡器它可用
張 旭

一位开发者的 Linux 容器之旅-技术 ◆ 学习|Linux.中国-开源社区 - 1 views

linux.cn/article-6594-1.html

linux docker container system development devops

shared by 張 旭 on 22 Nov 15 - No Cached
  • 容器是一个 Linux 进程，Linux 认为它只是一个运行中的进程。该进程只知道它被告知的东西。
  • 容器进程也分配了它自己的 IP 地址。
  • 在容器化方面，容器进程有它自己的 IP 地址。一旦给予了一个 IP 地址，该进程就是宿主网络中可识别的资源
  • ...20 more annotations...
  • 使容器 IP 映射到主机中能访问公网的 IP 地址。建立了该映射，无论出于什么意图和目的，容器就是网络上一个可访问的独立机器，从概念上类似于虚拟机。
  • 容器是拥有不同 IP 地址从而使其成为网络上可识别的独立 Linux 进程
  • CPU、内存和存储空间的分配是动态的，和典型虚拟机的静态方式不同。所有这些资源的共享都由容器管理器来管理。
  • 容器能非常快速地启动
  • 托管容器的计算机运行着被剥离的只剩下主要部分的某个 Linux 版本。
  • 操作系统被所有容器所共享，减少了容器足迹的重复和冗余。每个容器只包括该容器特有的部分
  • 层是一个容器镜像
  • 一个容器组件被称为层（layer）
  • 容器的各种功能都由一个称为容器管理器（container manager）的软件控制
  • 流行的容器管理器是 Docker 和 Rocket
  • 镜像存储在注册库（registry）中，注册库通过网络访问
  • 镜像代表了你的容器需要完成其工作的容器模板
  • 应用程序所需镜像的容器配置文件
  • 每个容器有一个独立的 IP 地址。因此，能把它放到负载均衡器后面。将容器放到负载均衡器后面，这就上升了一个层面。
  • Deis 的容器配置技术
  • 可以部署一个或多个容器镜像到主机上的负载均衡器下
  • 每次添加实例到环境中时，你不需要手动配置负载均衡器以便接受你的容器镜像。你可以使用服务发现技术让容器告知均衡器它可用。
  • 类似 CoreOS、RHEL Atomic、和 Ubuntu 的 Snappy 宿主操作系统
  • 类似 Docker 和 Rocket 的容器管理技术结合起来
  • 类似 Deis 这样的配置技术使容器创建和部署变得更加简单
張 旭

phusion/baseimage-docker - 1 views

github.com/...baseimage-docker

docker ubuntu base system

shared by 張 旭 on 24 Jun 15 - No Cached
    • 張 旭
      張 旭 on 24 Jun 15
       
      原始的 docker 在執行命令時，預設就是將傳入的 COMMAND 當成 PID 1 的程序，執行完畢就結束這個  docker，其他的 daemons 並不會執行，而 baseimage 解決了這個問題。
    • crazylion lee
      crazylion lee on 17 Dec 15
       
      好棒棒
  • docker exec
  • Through SSH
  • ...57 more annotations...
  • docker exec -t -i YOUR-CONTAINER-ID bash -l
  • Login to the container
  • Baseimage-docker only advocates running multiple OS processes inside a single container.
  • Password and challenge-response authentication are disabled by default. Only key authentication is allowed.
  • A tool for running a command as another user
  • The Docker developers advocate the philosophy of running a single logical service per container. A logical service can consist of multiple OS processes.
  • All syslog messages are forwarded to "docker logs".
  • Splitting your logical service into multiple OS processes also makes sense from a security standpoint.
  • Baseimage-docker provides tools to encourage running processes as different users
  • sometimes it makes sense to run multiple services in a single container, and sometimes it doesn't.
  • Baseimage-docker advocates running multiple OS processes inside a single container, and a single logical service can consist of multiple OS processes.
  • using environment variables to pass parameters to containers is very much the "Docker way"
  • add additional daemons (e.g. your own app) to the image by creating runit entries.
  • the shell script must run the daemon without letting it daemonize/fork it.
  • All executable scripts in /etc/my_init.d, if this directory exists. The scripts are run in lexicographic order.
  • variables will also be passed to all child processes
  • Environment variables on Unix are inherited on a per-process basis
  • there is no good central place for defining environment variables for all applications and services
  • centrally defining environment variables
  • One of the ideas behind Docker is that containers should be stateless, easily restartable, and behave like a black box.
  • a one-shot command in a new container
  • immediately exit after the command exits,
  • However the downside of this approach is that the init system is not started. That is, while invoking COMMAND, important daemons such as cron and syslog are not running. Also, orphaned child processes are not properly reaped, because COMMAND is PID 1.
  • Baseimage-docker provides a facility to run a single one-shot command, while solving all of the aforementioned problems
  • Nginx is one such example: it removes all environment variables unless you explicitly instruct it to retain them through the env configuration option.
  • Mechanisms for easily running multiple processes, without violating the Docker philosophy
  • Ubuntu is not designed to be run inside Docker
  • According to the Unix process model, the init process -- PID 1 -- inherits all orphaned child processes and must reap them
  • Syslog-ng seems to be much more stable
  • cron daemon
  • Rotates and compresses logs
  • /sbin/setuser
  • A tool for installing apt packages that automatically cleans up after itself.
  • a single logical service inside a single container
  • A daemon is a program which runs in the background of its system, such as a web server.
  • The shell script must be called run, must be executable, and is to be placed in the directory /etc/service/<NAME>. runsv will switch to the directory and invoke ./run after your container starts.
  • If any script exits with a non-zero exit code, the booting will fail.
  • If your process is started with a shell script, make sure you exec the actual process, otherwise the shell will receive the signal and not your process.
  • any environment variables set with docker run --env or with the ENV command in the Dockerfile, will be picked up by my_init
  • not possible for a child process to change the environment variables of other processes
  • they will not see the environment variables that were originally passed by Docker.
  • We ignore HOME, SHELL, USER and a bunch of other environment variables on purpose, because not ignoring them will break multi-user containers.
  • my_init imports environment variables from the directory /etc/container_environment
  • /etc/container_environment.sh - a dump of the environment variables in Bash format.
  • modify the environment variables in my_init (and therefore the environment variables in all child processes that are spawned after that point in time), by altering the files in /etc/container_environment
  • my_init only activates changes in /etc/container_environment when running startup scripts
  • environment variables don't contain sensitive data, then you can also relax the permissions
  • Syslog messages are forwarded to the console
  • syslog-ng is started separately before the runit supervisor process, and shutdown after runit exits.
  • RUN apt-get update && apt-get upgrade -y -o Dpkg::Options::="--force-confold"
  • /sbin/my_init --skip-startup-files --quiet --
  • By default, no keys are installed, so nobody can login
  • provide a pregenerated, insecure key (PuTTY format)
  • RUN /usr/sbin/enable_insecure_key
  • docker run YOUR_IMAGE /sbin/my_init --enable-insecure-key
  • RUN cat /tmp/your_key.pub >> /root/.ssh/authorized_keys && rm -f /tmp/your_key.pub
  • The default baseimage-docker installs syslog-ng, cron and sshd services during the build process
snow9816

Apache 中 KeepAlive 配置的合理使用 - 煎炸熊の記事本 - 0 views

note.artchiu.org/...%88%E7%90%86%E4%BD%BF%E7%94%A8

apache keep alive

shared by snow9816 on 03 Oct 16 - No Cached
  • KeepAlive 配置指令決定當處理完用戶發起的 HTTP 請求後是否立即關閉 TCP 連接，如果 KeepAlive 設置為On，那麼用戶完成一次訪問後，不會立即斷開連接，如果還有請求，那麼會繼續在這一次 TCP 連接中完成，而不用重複建立新的 TCP 連接和關閉TCP 連接，可以提高用戶訪問速度。
  • 那麼我們考慮3種情況： 1。用戶瀏覽一個網頁時，除了網頁本身外，還引用了多個 javascript 文件，多個 css 文件，多個圖片文件，並且這些文件都在同一個 HTTP 服務器上。 2。用戶瀏覽一個網頁時，除了網頁本身外，還引用一個 javascript 文件，一個圖片文件。 3。用戶瀏覽的是一個動態網頁，由程序即時生成內容，並且不引用其他內容。 對於上面3中情況，我認為：1 最適合打開 KeepAlive ，2 隨意，3 最適合關閉 KeepAlive
  • 假設 KeepAlive 的超時時間為 10 秒種，服務器每秒處理 50個獨立用戶訪問，那麼系統中 Apache 的總進程數就是 10 * 50 ＝ 500 個，如果一個進程佔用 4M 內存，那麼總共會消耗 2G內存
張 旭

我必须得告诉大家的MySQL优化原理 - 简书 - 0 views

www.jianshu.com/d7665192aaaf

mysql performance system

shared by 張 旭 on 19 Aug 17 - No Cached
  • 很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已
  • MySQL客户端/服务端通信协议是“半双工”的：在任一时刻，要么是服务器向客户端发送数据，要么是客户端向服务器发送数据，这两个动作不能同时发生。
  • 当查询语句很长的时候，需要设置max_allowed_packet参数。
  • ...70 more annotations...
  • 如果查询实在是太大，服务端会拒绝接收更多数据并抛出异常
  • 服务器响应给用户的数据通常会很多，由多个数据包组成
  • 减小通信间数据包的大小和数量是一个非常好的习惯
  • 查询中尽量避免使用SELECT *以及加上LIMIT限制
  • 在解析一个查询语句前，如果查询缓存是打开的，那么MySQL会检查这个查询语句是否命中查询缓存中的数据。
  • 两个查询在任何字符上的不同（例如：空格、注释），都会导致缓存不会命中。
  • MySQL将缓存存放在一个引用表
  • 如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表，其查询结果 都不会被缓存。
  • MySQL的查询缓存系统会跟踪查询中涉及的每个表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效。
  • 在任何的写操作时，MySQL必须将对应表的所有缓存都设置为失效。
  • 查询缓存对系统的额外消耗也不仅仅在写操作，读操作也不例外
  • 任何的查询语句在开始之前都必须经过检查，即使这条SQL语句永远不会命中缓存
  • 如果查询结果可以被缓存，那么执行完成后，会将结果存入缓存，也会带来额外的系统消耗
  • 并不是什么情况下查询缓存都会提高系统性能，缓存和失效都会带来额外消耗
  • 用多个小表代替一个大表
  • 批量插入代替循环单条插入
  • 合理控制缓存空间大小
  • 可以通过SQL_CACHE和SQL_NO_CACHE来控制某个查询语句是否需要进行缓存
  • 不要轻易打开查询缓存，特别是写密集型应用
  • 将query_cache_type设置为DEMAND，这时只有加入SQL_CACHE的查询才会走缓存，其他查询则不会，这样可以非常自由地控制哪些查询需要被缓存。
  • 预处理则会根据MySQL规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等。
  • 一条查询可以有很多种执行方式，最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。
  • 查询当前会话的last_query_cost的值来得到其计算当前查询的成本。
  • 尝试预测一个查询使用某种执行计划时的成本
  • 有非常多的原因会导致MySQL选择错误的执行计划
  • MySQL值选择它认为成本小的，但成本小并不意味着执行时间短
  • 提前终止查询（比如：使用Limit时，查找到满足数量的结果集后会立即终止查询）
  • 找某列的最小值，如果该列有索引，只需要查找B+Tree索引最左端，反之则可以找到最大值
  • 在完成解析和优化阶段以后，MySQL会生成对应的执行计划，查询执行引擎根据执行计划给出的指令逐步执行得出结果。
  • 查询过程中的每一张表由一个handler实例表示。
  • MySQL在查询优化阶段就为每一张表创建了一个handler实例，优化器可以根据这些实例的接口来获取表的相关信息
  • 即使查询不到数据，MySQL仍然会返回这个查询的相关信息，比如改查询影响到的行数以及执行时间等等。
  • 结果集返回客户端是一个增量且逐步返回的过程
  • 整型就比字符操作代价低，因而会使用整型来存储ip地址，使用DATETIME来存储时间，而不是使用字符串。
  • 如果计划在列上创建索引，就应该将该列设置为NOT NULL
  • UNSIGNED表示不允许负值，大致可以使正数的上限提高一倍。
  • 没有太大的必要使用DECIMAL数据类型。即使是在需要存储财务数据时，仍然可以使用BIGINT
  • 大表ALTER TABLE非常耗时
  • MySQL执行大部分修改表结果操作的方法是用新的结构创建一个张空表，从旧表中查出所有的数据插入新表，然后再删除旧表
  • 索引是提高MySQL查询性能的一个重要途径，但过多的索引可能会导致过高的磁盘使用率以及过高的内存占用，从而影响应用程序的整体性能。
  • 索引是指B-Tree索引，它是目前关系型数据库中查找数据最为常用和有效的索引，大多数存储引擎都支持这种索引
  • B+Tree中的B是指balance，意为平衡。
  • 平衡二叉树首先需要符合二叉查找树的定义，其次必须满足任何节点的两个子树的高度差不能大于1。
  • 索引往往以索引文件的形式存储的磁盘上
  • 如何减少查找过程中的I/O存取次数？
  • 减少树的深度，将二叉树变为m叉树（多路搜索树），而B+Tree就是一种多路搜索树。
  • 页是计算机管理存储器的逻辑块，硬件及OS往往将主存和磁盘存储区分割为连续的大小相等的块
  • B+Tree为了保持平衡，对于新插入的值需要做大量的拆分页操作，而页的拆分需要I/O操作，为了尽可能的减少页的拆分操作，B+Tree也提供了类似于平衡二叉树的旋转功能。
  • 在多数情况下，在多个列上建立独立的索引并不能提高查询性能。理由非常简单，MySQL不知道选择哪个索引的查询效率更好
  • 当出现多个索引做联合操作时（多个OR条件），对结果集的合并、排序等操作需要耗费大量的CPU和内存资源，特别是当其中的某些索引的选择性不高，需要返回合并大量数据时，查询成本更高。
  • explain时如果发现有索引合并（Extra字段出现Using union），应该好好检查一下查询和表结构是不是已经是最优的
  • 索引选择性是指不重复的索引值和数据表的总记录数的比值
  • 唯一索引的选择性是1，这时最好的索引选择性，性能也是最好的。
  • 如果一个索引包含或者说覆盖所有需要查询的字段的值，那么就没有必要再回表查询，这就称为覆盖索引。
  • 对结果集进行排序的操作
  • 按照索引顺序扫描得出的结果自然是有序的
  • 如果explain的结果中type列的值为index表示使用了索引扫描来做排序。
  • 在设计索引时，如果一个索引既能够满足排序，有满足查询，是最好的。
  • 比如有一个索引(A,B)，再创建索引(A)就是冗余索引。
  • 对于非常小的表，简单的全表扫描更高效。对于中到大型的表，索引就非常有效。对于超大型的表，建立和维护索引的代价随之增长，这时候其他技术也许更有效，比如分区表。
  • explain后再提测是一种美德。
  • 如果要统计行数，直接使用COUNT(*)，意义清晰，且性能更好。
  • 执行EXPLAIN并不需要真正地去执行查询，所以成本非常低。
  • 确保ON和USING字句中的列上有索引。在创建索引的时候就要考虑到关联的顺序
  • 确保任何的GROUP BY和ORDER BY中的表达式只涉及到一个表中的列，这样MySQL才有可能使用索引来优化
  • MySQL关联执行的策略非常简单，它对任何的关联都执行嵌套循环关联操作，即先在一个表中循环取出单条数据，然后在嵌套循环到下一个表中寻找匹配的行，依次下去，直到找到所有表中匹配的行为为止。然后根据各个表匹配的行，返回查询中需要的各个列。
  • 最外层的查询是根据A.xx列来查询的，A.c上如果有索引的话，整个关联查询也不会使用。再看内层的查询，很明显B.c上如果有索引的话，能够加速查询，因此只需要在关联顺序中的第二张表的相应列上创建索引即可。
  • MySQL处理UNION的策略是先创建临时表，然后再把各个查询结果插入到临时表中，最后再来做查询。
  • 要使用UNION ALL，如果没有ALL关键字，MySQL会给临时表加上DISTINCT选项，这会导致整个临时表的数据做唯一性检查，这样做的代价非常高。
  • 尽可能不要使用存储过程
張 旭

深度解读 - TDD（测试驱动开发） - 简书 - 0 views

www.jianshu.com/62f16cd4fef3

development programming test

shared by 張 旭 on 31 Mar 17 - No Cached
  • TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
  • TDD 并不能直接提高设计能力，它只是给你更多机会和保障去改善设计。
  • 写测试，只关注需求，程序的输入输出，不关心中间过程
  • ...21 more annotations...
  • 写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可
  • 一次只关注一个点，思维负担更小
  • 提前澄清需求细节
  • 写一个失败的测试，它是对一个小需求的描述，只需要关心输入输出，这个时候根本不用关心如何实现
  • 专注在用最快的方式实现当前这个小需求，不用关心其他需求，也不要管代码的质量多么惨不忍睹
  • 既不用思考需求，也没有实现的压力，只需要找出代码中的坏味道，并用一个手法消除它，让代码变成整洁的代码
  • TDD 之前要拆分任务，把一个大需求拆成多个小需求。
  • 符合 Given-When-Then 格式
  • 包含断言
  • 可以重复执行
  • 单元测试基础设施
  • 只在没有信心的地方写测试代码
  • 有注释的地方都可以抽取方法，用方法名来代替注释
  • 选一个最简单的用例，直接开写，用最简单的代码通过测试。逐渐增加测试，让代码变复杂，用重构来驱动出设计。
  • 有了重构这个工具后，做设计的压力小了很多，因为有测试代码保护，我们可以随时重构实现了
  • 在纸上迭代总比改代码要快
  • 任务分解和列 Example
  • 步子迈太大，容易扯着蛋。
  • 做探索性的技术研究（Spike），不需要长期维护，而且测试基础设施搭建成本很高，那还是手工测试吧
  • TDD 是开发人员自己的事
  • 布置完一个任务，让新人先画图，就可以在他开始写代码前对他的设计提反馈。
  • 張 旭 on 31 Mar 17
     
    "TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。"
張 旭

在 EKS 中实现基于 Promtail + Loki + Grafana 容器日志解决方案 - 0 views

mp.weixin.qq.com/...Qotk0CNgsBrFy0Ot7AL0jQ

log kubernetes docker system

shared by 張 旭 on 31 May 21 - No Cached
  • Grafana大家应该都比较熟悉，它是一款开源的可视化和分析软件，它允许用户查询、可视化、警告和探索监控指标。Grafana主要提供时间序列数据的仪表板解决方案，支持超过数十种数据源（还在陆续添加支持中）
  • Grafana Loki是一组可以组成一个功能齐全的日志堆栈组件，与其它日志系统不同的是，Loki只建立日志标签的索引而不索引原始日志消息，而是为日志数据设置一组标签，这意味着Loki的运营成本更低，效率也能提高几个数量级。
  • Loki整体架构也是由不同的组件来协同完成日志收集、索引、存储等工作
  • ...5 more annotations...
  • 一句话形容下Loki就是like Prometheus, but for logs。
  • Promtail是一个日志收集的代理，它会将本地日志的内容发送到一个Loki实例，它通常部署到需要监视应用程序的每台机器/容器上。Promtail主要是用来发现目标、将标签附加到日志流以及将日志推送到Loki。
  • Loki中的日志带有一组标签名和值，其中只有标签对被索引，这种权衡使得它比完整索引的操作成本更低，但是针对基于内容的查询，需要通过LogQL再单独查询。
  • 和Fluentd相比，Promtail是专门为Loki量身定制的，它可以为运行在同一节点上的Kubernetes Pods做服务发现，从指定文件夹读取日志。
  • 亚马逊云科技也提供了Grafana和Prometheus的托管服务Amazon Managed Service for Grafana（AMG）和Amazon Managed Service for Prometheus（AMP）
張 旭

鳥哥的 Linux 私房菜 -- 第一章、Linux是什麼與如何學習 - 0 views

linux.vbird.org/...0110whatislinux.php

system linux

shared by 張 旭 on 22 Jun 21 - Cached
  • Linux就是核心與系統呼叫介面那兩層
  • 核心與硬體的關係非常的強烈
  • Linux提供了一個完整的作業系統當中最底層的硬體控制與資源管理的完整架構， 這個架構是沿襲Unix良好的傳統來的，所以相當的穩定而功能強大
  • ...31 more annotations...
  • Linux的核心是由Linus Torvalds在1991年的時候給他開發出來的， 並且丟到網路上提供大家下載，後來大家覺得這個小東西(Linux Kernel)相當的小而精巧， 所以慢慢的就有相當多的朋友投入這個小東西的研究領域裡面去
  • 1960年代初期麻省理工學院(MIT)發展了所謂的： 『相容分時系統(Compatible Time-Sharing System, CTSS)』， 它可以讓大型主機透過提供數個終端機(terminal)以連線進入主機，來利用主機的資源進行運算工作
  • 為了更加強化大型主機的功能，以讓主機的資源可以提供更多使用者來利用，所以在1965年前後， 由貝爾實驗室(Bell)、麻省理工學院(MIT)及奇異公司(GE, 或稱為通用電器)共同發起了Multics的計畫
  • 以組合語言(Assembler)寫出了一組核心程式，同時包括一些核心工具程式， 以及一個小小的檔案系統。那個系統就是Unix的原型！ 當時Thompson將Multics龐大的複雜系統簡化了不少，於是同實驗室的朋友都戲稱這個系統為：Unics。(當時尚未有Unix的名稱)
  • 所有的程式或系統裝置都是檔案
  • 不管建構編輯器還是附屬檔案，所寫的程式只有一個目的，且要有效的完成目標。
  • Dennis Ritchie (註3) 將B語言重新改寫成C語言，再以C語言重新改寫與編譯Unics的核心， 最後正名與發行出Unix的正式版本！
  • 由於Unix是以較高階的C語言寫的，相對於組合語言需要與硬體有密切的配合， 高階的C語言與硬體的相關性就沒有這麼大了！所以，這個改變也使得Unix很容易被移植到不同的機器上面喔！
  • AT&T此時對於Unix是採取較開放的態度，此外，Unix是以高階的C語言寫成的， 理論上是具有可移植性的！亦即只要取得Unix的原始碼，並且針對大型主機的特性加以修訂原有的原始碼(Source Code)， 就可能將Unix移植到另一部不同的主機上頭了。
  • 柏克萊大學的Bill Joy (註4)在取得了Unix的核心原始碼後，著手修改成適合自己機器的版本， 並且同時增加了很多工具軟體與編譯程式，最終將它命名為Berkeley Software Distribution (BSD)。
  • 每一家公司自己出的Unix雖然在架構上面大同小異，但是卻真的僅能支援自身的硬體， 所以囉，早先的Unix只能與伺服器(Server)或者是大型工作站(Workstation)劃上等號！
  • AT&T在1979年發行的第七版Unix中，特別提到了 『不可對學生提供原始碼』的嚴格限制！
  • 純種的Unix指的就是System V以及BSD
  • AT&T自家的System V
  • 既然1979年的Unix第七版可以在Intel的x86架構上面進行移植， 那麼是否意味著可以將Unix改寫並移植到x86上面了呢？在這個想法上， 譚寧邦教授於是乎自己動手寫了Minix這個Unix Like的核心程式！
  • 『既然作業系統太複雜，我就先寫可以在Unix上面運行的小程式，這總可以了吧？』
  • 如果能夠寫出一個不錯的編譯器，那不就是大家都需要的軟體了嗎？ 因此他便開始撰寫C語言的編譯器，那就是現在相當有名的GNU C Compiler(gcc)！
  • 他還撰寫了更多可以被呼叫的C函式庫(GNU C library)，以及可以被使用來操作作業系統的基本介面BASH shell！ 這些都在1990年左右完成了！
  • 有鑑於圖形使用者介面(Graphical User Interface, GUI) 的需求日益加重，在1984年由MIT與其他協力廠商首次發表了X Window System ，並且更在1988年成立了非營利性質的XFree86這個組織。所謂的XFree86其實是 X Window System + Free + x86的整合名稱呢！
  • 譚寧邦教授為了教育需要而撰寫的Minix系統！ 他在購買了最新的Intel 386的個人電腦後，就立即安裝了Minix這個作業系統。 另外，上個小節當中也談到，Minix這個作業系統是有附上原始碼的， 所以托瓦茲也經由這個原始碼學習到了很多的核心程式設計的設計概念喔！
  • 托瓦茲自己也說：『我始終是個性能癖』^_^。 為了徹底發揮386的效能，於是托瓦茲花了不少時間在測試386機器上！ 他的重要測試就是在測試386的多功性能。首先，他寫了三個小程式，一個程式會持續輸出A、一個會持續輸出B， 最後一個會將兩個程式進行切換。他將三個程式同時執行，結果，他看到螢幕上很順利的一直出現ABABAB...... 他知道，他成功了！ ^_^
  • 為了讓所有的軟體都可以在Linux上執行，於是托瓦茲開始參考標準的POSIX規範。
  • POSIX是可攜式作業系統介面(Portable Operating System Interface)的縮寫，重點在規範核心與應用程式之間的介面， 這是由美國電器與電子工程師學會(IEEE)所發佈的一項標準喔
  • 因為托瓦茲放置核心的那個FTP網站的目錄為：Linux， 從此，大家便稱這個核心為Linux了。(請注意，此時的Linux就是那個kernel喔！ 另外，托瓦茲所丟到該目錄下的第一個核心版本為0.02呢！)
  • Linux其實就是一個作業系統最底層的核心及其提供的核心工具。 他是GNU GPL授權模式，所以，任何人均可取得原始碼與可執行這個核心程式，並且可以修改。
  • Linux參考POSIX設計規範，於是相容於Unix作業系統，故亦可稱之為Unix Like的一種
  • 為了讓使用者能夠接觸到Linux，於是很多的商業公司或非營利團體， 就將Linux Kernel(含tools)與可運行的軟體整合起來，加上自己具有創意的工具程式， 這個工具程式可以讓使用者以光碟/DVD或者透過網路直接安裝/管理Linux系統。 這個『Kernel + Softwares + Tools + 可完整安裝程序』的咚咚，我們稱之為Linux distribution， 一般中文翻譯成可完整安裝套件，或者Linux發佈商套件等。
  • 在1994年終於完成的Linux的核心正式版！version 1.0。 這一版同時還加入了X Window System的支援呢！且於1996年完成了2.0版、2011 年釋出 3.0 版，更於 2015 年 4 月釋出了 4.0 版哩！ 發展相當迅速喔！此外，托瓦茲指明了企鵝為Linux的吉祥物。
  • Linux本身就是個最陽春的作業系統，其開發網站設立在http://www.kernel.org，我們亦稱Linux作業系統最底層的資料為『核心(Kernel)』。
  • 常見的 Linux distributions 分類有『商業、社群』分類法，或『RPM、DPKG』分類法
  • 事實上鳥哥認為distributions主要分為兩大系統，一種是使用RPM方式安裝軟體的系統，包括Red Hat, Fedora, SuSE等都是這類； 一種則是使用Debian的dpkg方式安裝軟體的系統，包括Debian, Ubuntu, B2D等等。
1 - 20 of 20
Showing 20▼ items per page